Comment créer des Composants en AS3 ?
Après avoir vu ensemble les différentes raisons (Chapitre 1 : Pourquoi créer des Composants Graphiques en AS3 ?), nous allons aborder le thème de leur conception.
La façon de concevoir des composants se doit d’être souple. Il est donc nécessaire d’adapter son processus de développement en fonction du type de projet sur lequel nous travaillons.
La méthode qui vous est décrite est basée sur l’expérience, un vécu de programmeur. Après la lecture de ce tutoriel, vous possèderez toutes les clés pour améliorer vos Composants AS3 selon vos besoins spécifiques. C’est un petit peu cela la magie du développement!
Si il n’y a qu’une seule et unique règle d’or à retenir c’est : « Soyez rigoureux, codez avec souplesse ! ».
I – Le Cahier Des Charges Fonctionnel
Ah le cahier des charges fonctionnel, aussi appelé CDCF, un vaste programme ô combien primordial ! Sachez que c’est l’une des étapes les plus importantes si ce n’est la plus importante de tout projet informatique.
Un CDCF correctement décrit et validé c’est des dizaines d’heures de code économisées.
Dans un monde idéal, tout projet informatique devrait démarrer avec un Cahier Des Charges Fonctionnel.
Concrètement, c’est quoi un CDCF ?
Un cahier des charges fonctionnel est un document qui décrit de la manière la plus exhaustive possible la liste des actions et fonctionnalités dont votre programme devra être dôté en fin de production.
Comprenez par là que toute personne, et surtout non versée dans le développement, sera à même de vous décrire le fonctionnement détaillé de votre future application sous réserve d’avoir lu ce fameux CDCF.
Pour vous donner un exemple plus concret, cela ressemble à un story-board au cinéma. Un story-board va vous décrire l’enchaînement des actions, de la scène, le placement, l’attitude des acteurs. Et bien un CDCF est un story-board informatique.
Imaginons un instant la scène suivante :
- Eh Tom !
- Oui chef ?
- Laisses tomber ce que tu fais et viens voir un peu là, on a nouveau projet à démarrer !
- Ah ? Très bien de quel genre de projet s’agit-il ?
- Il s’agit d’un site e-commerce.
- Mmmh ok, je t’écoute.
- Le client veut quelque chose de classe et sobre, une vitrine en somme, seulement les clients devront pouvoir acheter ses produits par le biais d’une boutique en ligne.Ah et j’oubliais de préciser il ne veut pas que son site soit développé en PHP et n’aime pas Flash ! Alors tu te sens d’attaque ?
- Mmmh j’aurais besoin d’un peu plus de précision, pourquoi ne veux-t-il pas de PHP sur son site ? Quelle plateforme de paiement désire-t-il utiliser ? Ce que je veux dire c’est qu’il me faudrait un peu plus de renseignements que ça.
- Oui enfin bon, le truc c’est qu’il est assez pressé vois-tu, il a besoin d’une démo pour se décider, je compte sur toi pour faire au mieux et pour les précisions je te les donnerai au fur et à mesure, là tu as l’essentiel. Tu penses que la démo peut être prête pour demain midi afin que je lui soumette ?
- Je vais faire de mon mieux, seulement je ne peux pas te garantir que cela va lui plaire.
- N’oublies pas que je compte sur toi, t’es le meilleur !
Alors ? Un air de déjà vu ? Si non, ça ne saurait tarder ! En effet, il s’agit là d’un dialogue classique entre un développeur et un commercial / chef de projet.
Pauvre Tom… Il va être bien embêté pour réaliser sa démo. Eh oui, à aucun moment son chef ne lui a donné de direction précise vers laquelle s’orienter, comptant sur le seul talent de son employé.
Seulement voilà, Tom est développeur, pas magicien! Il ne peut deviner ce à quoi pense le client, il a donc 90% de chance de se planter!
Sa seule consolation, c’est qu’il y a peu de chance que ses concurrents possèdent plus d’informations.
Maintenant vous avez saisi l’importance de la rédaction d’un bon CDCF. Un Cahier Des Charges Fonctionnel contient la liste des fonctionnalités et des actions de votre programme.
Ensuite, nous passons à la rédaction du Cahier Des Charges Technique que nous abrègerons par CDCT.
II – Le Cahier Des Charges Technique
Le CDCT est un chantier aussi vaste que le CDCF, toutefois sa conception est nettement plus simple. En général il est réalisé par des programmeurs pour des programmeurs! C’est un avantage certain, en effet, tous les protagonistes « parlent » le même langage.
Le CDCT est un élément intermédiaire, à cheval entre le CDCF et la production. Il permet aux développeurs d’avoir une référence sur laquelle s’appuyer pour implémenter telle ou telle fonctionnalité.
Le Cahier Des Charges Technique existe pour décrire l’ensemble des librairies, frameworks, méthodes de développement qui seront employées en production. Il apporte également quelques précisions qui ne rentrent pas dans le cadre du Cahier Des Charges Fonctionnel ( par exemple le fait que le site devra être développé en Java et non en PHP ).
De plus le CDCT a également une autre utilité. Il permet de préparer le terrain pour l’élaboration du schéma architectural de l’application que nous verrons un peu plus loin.
Dans le cadre du développement d’un composant graphique, le Cahier Des Charges Technique servira à décrire la manière de développer les fonctionnalités que nous estimons génériques ou non.
Prenons un exemple tout simple et retrouvons notre ami Tom :
- Eh Tom ! Laisses-donc ce site e-commerce, de toute façon la démo n’a pas plus au client ! Viens voir un peu.
- Oui ?
- J’aimerais que tu développes une bibliothèque de composants graphiques génériques dont on pourra se resservir à loisir ! Le client est très exigeant et nous a fourni la liste des fonctionnalités qu’il souhaite trouver sur les différents éléments de cette bibliothèque.
- Très bien, dois-je coder de manière à pouvoir l’étendre facilement plus tard ? Pour les skins, est-ce que je fais un module à part ou directement dépendant de la bibliothèque ? Ai-je le droit d’utiliser des librairies externes comme des librairies de Tween ?
- Euuhhhh …. Fais comme tu le sens ! Au mieux !
- Disons qu’il est un peu difficile de dire ce qui est le mieux, tout dépend de ce que l’on souhaite en faire et de comment la bibliothèque est censée évoluer.
- Je te fais confiance, tu es le meilleur ! Et n’oublies pas que je compte sur toi !
Ahlala, décidément ce Tom a l’art de s’attirer des ennuis, ou peut être que sont-ce les aléas courants du métier, allez savoir…
Toujours est-il qu’il va être obligé de passer pas mal de temps à réfléchir à ce qui sera le mieux pour le futur de cette bibliothèque de composants. Et qui plus est, sans connaître les exigences particulières des équipes techniques du client.
Il est donc fort probable qu’à terme, il perde une bonne partie de son temps à redévelopper des fonctionnalités mais cette fois-ci, d’une manière qui convienne au client.
D’où l’importance de la rédaction d’un Cahier Des Charges Technique qui permet au développeur de développer plutôt telle ou telle fonctionnalité et d’en laisser une autre de côté (car inutile pour le client).
Maintenant, nous allons découvrir la création du schéma architectural de l’application.
III – Le schéma architectural de l’application
Le schéma architectural d’une application est, disons, INDISPENSABLE.
En effet, lorsque nous abordons pour la première fois une nouvelle librairie, nous disposons en général d’une documentation. Cependant, celle-ci nous renseigne rarement sur la façon dont les différents éléments interagissent entre eux.
Il s’agit donc d’une représentation imagée de l’emboîtement des différentes briques fonctionnelles du projet. Ainsi, nous connaissons, par exemple, que telle ou telle classe à des dépendances avec telle ou telle autre. Et nous pouvons déterminer assez aisément que cette classe à droite hérite de celle qui se trouve juste au dessus.
Le but de cet article n’étant pas de faire un cours magistral sur les méthodes de conception de ces schémas, en voici une : UML.
Et je vous invite grandement à approfondir vos connaissances sur le sujet. La documentation sur internet est nombreuse et qualitative pour que je me permette de vous laisser choisir vos propres sources.
Voici à titre d’exemple, ce à quoi peut ressembler un schéma UML, il s’agit d’un exemple pris sur internet au hasard des couloirs…
Comme vous pouvez le constater, l’application semble complexe. Toutefois grâce à notre schéma, nous pouvons aisément dissocier certains éléments. Nous pouvons même comprendre, grâce au sens des flèches, comment s’effectue la communication entre les différents éléments.
IV – Conclusion
Dans ce chapitre, nous avons vu que pour entamer un développement de la manière la plus sereine possible, il nous fallait au préalable préparer le terrain avec la rédaction :
- du Cahier Des Charges Fonctionnel (CDCF).
- du Cahier Des Charges Technique (CDCT).
- du Schéma Architectural.
Et cela, en étant le plus rigoureux possible afin de gagner du temps plus tard sur le développement.
Certes, au début tout cela peut vous paraître superflu voire franchement casse-pieds. Ces différentes méthodes ont fait leurs preuves maintes et maintes fois. Et elles continuent chaque jour, pour chaque application, de les faire.
Dans le prochain chapitre nous aborderons enfin la pratique avec le développement des fonctionnalités de base de notre bibliothèque de Composants AS3.
Et vous, comment effectuez-vous l’analyse de vos projets ActionScript ?
Avant le développement pur et dur, utilisez-vous des outils / logiciels spécifiques ?
Partagez votre expérience dans les commentaires ci-dessous.
Développement Facile