ActionScript Facile Chapitre 2 Comment créer des composants graphiques ?

Matthieu

Article original : ActionScript-Facile.com - Comment créer des composants graphiques ?

Commentez cet article : Commentez ♪

- Titre : ActionScript Facile Chapitre 2 Comment créer des composants graphiques ?

- Auteur : Matthieu

- Parution : 21 octobre 2010

- Licence : Copyright ® 2010 Matthieu - www.actionscript-facile.com. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Le Cahier Des Charges Fonctionnel

- III. Le Cahier Des Charges Technique

- IV. Le schéma architectural de l'application

- V. Conclusion

- VI. Remerciements/Téléchargements

I - Introduction

Après avoir vu ensemble les différentes raisons (Chapitre 1 : Pourquoi créer des composants graphiques ?) qui peuvent nous amener à développer des composants graphiques, nous allons aborder le thème ô combien vaste et complexe de leur conception.

Notez cependant que cet article n'a aucunement la prétention de décrire « la meilleure façon de faire » pour la bonne et simple raison que celle-ci n'existe tout simplement pas. La façon de concevoir des composants se doit d'être souple. De plus, il est 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, c'est-à-dire qu'ensuite vous posséderez toutes les clés pour améliorer chacun des composants AS3 selon vos besoins spécifiques. C'est un petit peu cela la magie du développement.

S'il n'y a qu'une seule et unique règle d'or que vous devez retenir à la suite de cet article c'est : « Soyez rigoureux, codez avec souplesse ! ».

Maintenant, passons aux choses sérieuses.

II - 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 doté 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 ?

- Laisse 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'oublie pas que je compte sur toi, t'es le meilleur !

Alors ? Un air de déjà vu ? Sinon, ç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 chances de se planter, sa seule consolation, c'est qu'il y a peu de chances que ses concurrents aient eut plus d'informations.

Maintenant vous avez saisi l'importance de la rédaction d'un bon CDCF. Je répète, un Cahier Des Charges Fonctionnel contient la liste des fonctionnalités et des actions de votre programme.

Il nous faut passer au Cahier Des Charges Technique que nous abrègerons CDCT.

III - 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, ce qui est un avantage certain, tous les protagonistes parlant 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 en cas d'hésitation sur la manière d'implémenter telle ou telle fonctionnalité.

Le Cahier Des Charges Technique est là 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 sont pas renseignées dans le cadre du Cahier Des Charges Fonctionnels (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 CDCT 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 ! Laisse donc ce site e-commerce, de toute façon la démo n'a pas plu 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'oublie pas que je compte sur toi !

Note : une Tween permet de créer des animations en utilisant des équations de mouvement mathématiques permettant de créer des mouvements naturels et non linéaires.
Adobe a intégré cette fonctionnalité dans Flash MX 2004 pour donner du mordant à ses composants et depuis, la classe mx.transitions.Tween reste un grand classique.

Reprenons l'histoire de notre ami programmeur : Tom.

Ahlala, décidément ce Tom a l'art de s'attirer des ennuis, ou peut-être que ce sont 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 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 passer au schéma architectural de l'application.

IV - 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 étant assez 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.

V - 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 :

1. Du Cahier Des Charges Fonctionnel (CDCF) ;

2. Du Cahier Des Charges Technique (CDCT) ;

3. 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-pied, mais ces 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.

VI - Remerciements/Téléchargements

Je tiens ici à remercier La Rédactrice Kalyparker pour la mise au gabarit de l'article original au format Developpez.com.

Merci beaucoup à l'équipe Developpez.com de contribuer à la diffusion du Framework ActionScript-Facile.

Téléchargez l'ensemble des classes commentées du Framework AS3 Facile (avec le code source et les exemples de tous les Composants AS3).