Conception logicielle

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. 1x01.png

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. 1x02.png

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. 1x03.png

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. 1x04.png

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'architectureConcepts d'implémentationDétails d'implémentation
DépendancesNe dépendent que d'autres concepts d'architecturePeuvent dépendre de concepts d'architecture ou de d'autres concepts d'implémentationDépendent de concepts d'architecture et de concepts d'implémentation
Niveau d'abstractionEntièrement abstraitsMélange d'abstraction et de détailsEntièrement composés de détails
Niveau de stabilitéStabilité maximalePartiellement stableChange au moindre changement dans le logiciel

Dans un prochain billet, on parlera de la formation et de l'évolution de ces divers éléments.