Conception logicielle
05 mar. 2012 Olivier Azeau En français 0
Une pratique utile à tout développeur de logiciels est l'analyse de son propre travail[1]. C'est dans cet esprit que j'entame aujourd'hui une petite série de billets sur la conception de logiciels, ou, plus précisément, ce qu'est, à cet instant, pour moi, la conception de logiciels.
C'est à la fois une façon de faire un point personnel sur ce que j'ai appris[2], de le partager avec tous ceux qui pourraient être intéressés[3], et enfin de l'exposer à la critique publique de ceux qui prendront le temps de le lire[4].
Dans cette série de billets, je compte donc aborder les points qui me paraissent les plus importants dans la conception, la manière dont ils évoluent au fil du temps, le contrôle qu'exerce un développeur sur cette évolution et les relations qu'entretient le logiciel avec son environnement.
Avant de parler de "conception" logicielle, il me faut définir le terme.
Le dictionnaire de l'académie française[5] propose plusieurs définition pour la conception. Celle-ci me parait adaptée.
Conception : Action de former le concept d'un objet
Allons voir la définition d'un concept. Il y en a, là aussi, plusieurs mais je prends celle qui me convient le mieux :
Concept : Construction de l'esprit explicitant un ensemble stable de caractères communs désigné par un signe verbal.
Ainsi, j'ai envie de dire que concevoir un logiciel, c'est nommer et décrire ce que partagent les divers éléments qui le composent. Ce partage induit une dépendance des divers éléments, les détails, envers ce qu'ils ont en commun.
Ceci étant, tous les concepts n'ont pas la même nature. J'en distingue deux :
- Certains concepts sont omniprésent sur l'ensemble du logiciel. Ils permettent de décrire, par exemple, le domaine métier que le logiciel manipule[6] ou encore les contrats que respectent les divers éléments quand ils dialoguent les uns avec les autres[7].
- D'autres concepts n'ont de raison d'être que par rapport à une tactique de réalisation du logiciel. Un élément va, par exemple, utiliser une évaluation paresseuse[8] pour optimiser les performances ; d'autres élements aux algorithmes similaires vont partager un patron de méthode[9] ; etc.
Intéressons-nous au premier cas. Les concepts omniprésents sont la base sans laquelle le logiciel ne pourrait exister. Ils décrivent la manière dont les élements de détail sont agencés les uns par rapport aux autres. Il y a un mot qui me rappelle cette idée de mise en forme globale d'une construction :
Architecture : Disposition, ordonnance d'un édifice.
On pourrait donc parler de concepts d'architecture.
Faisons un zoom sur le schema précédent pour apercevoir les packages qui composent le logiciel. On entend ici par package des bouts de code dont le contenu est lié par un destin commun, tant du point de vue de l'utilisation que de la modification[10]. On a, en bleu, les packages contenant les concepts d'architecture et, en rouge, les détails de réalisation du logiciel.
Faisons un aparté rapide pour préciser que l'association implicite "concept <-> bouts de code" n'a rien d'étonnant. On peut dessiner un concept sur un tableau ; on peut le décrire dans un document mais s'il n'est pas présent explicitement dans le code, il n'existe pas !
Si on fait un nouveau zoom, on découvre les concepts d'implémentation qui constituent les choix de construction des détails. A priori, ces concepts sont internes aux packages de détails car l'utilisation d'un entre eux dans un package n'a aucune implication sur les autres packages. Sur le schéma suivant, les concepts d'implémentation sont représentés en beige.
Toutefois, il arrive que certains de ces concepts soient utilisés dans plusieurs situations indépendantes. Ils intègrent alors, pour des raisons pratiques, des packages partagés.
On se retrouve ainsi avec plusieurs niveaux de définition d'un logiciel sur lesquels on doit pouvoir vérifier les progressions habituelles d'abstraction et de stabilité[11].
Concepts d'architecture | Concepts d'implémentation | Détails d'implémentation | |
---|---|---|---|
Dépendances | Ne dépendent que d'autres concepts d'architecture | Peuvent dépendre de concepts d'architecture ou de d'autres concepts d'implémentation | Dépendent de concepts d'architecture et de concepts d'implémentation |
Niveau d'abstraction | Entièrement abstraits | Mélange d'abstraction et de détails | Entièrement composés de détails |
Niveau de stabilité | Stabilité maximale | Partiellement stable | Change au moindre changement dans le logiciel |
Dans un prochain billet, on parlera de la formation et de l'évolution de ces divers éléments.
Notes
[1] Apprenticeship Patterns "Reflect as you work" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#reflect_as_you_work
[2] Apprenticeship Patterns "Record what you learn" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#record_what_you_learn
[3] Apprenticeship Patterns "Share what you learn" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#share_what_you_learn
[4] Apprenticeship Patterns "Create feedback loops" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#create_feedback_loops
[5] http://www.academie-francaise.fr/dictionnaire/
[6] http://en.wikipedia.org/wiki/Domain_model
[7] http://en.wikipedia.org/wiki/Interface_%28computing%29
[8] http://en.wikipedia.org/wiki/Lazy_evaluation
[9] http://en.wikipedia.org/wiki/Template_method_pattern
[10] http://www.objectmentor.com/resources/articles/granularity.pdf
[11] http://www.objectmentor.com/resources/articles/stability.pdf