16 juil. 2010

Architecte ou designer ?

Sur ce blog, j'ai beaucoup utilisé les termes "architecture" et "design" (ou son pendant français, "conception") sans me douter un instant que vous pourriez penser que ces deux termes sont complètement interchangeables - alors que, formellement, ce n'est pas tout à fait le cas. Et parce que j'aime l'histoire, je vais tenter d'expliquer les différences qui peuvent exister entre le métier d'architecte logiciel et celui de concepteur logiciel.

Qu'est-ce que le design logiciel ?

Le design logiciel est l'action de définir la structure statique et dynamique d'un logiciel. Cette définition peut être implicite (le code) ou explicite (un document de design). En tout état de cause, l'activité elle-même n'a pas besoin d'être formelle. D'ailleurs elle ne l'est que très rarement : combien de fois avez-vous codé un bout de logiciel en vous fiant à votre seule intuition pour ce qui est de la structure ? Personnellement, ça m'est arrivé tellement souvent que j'en ai presque honte.

Historiquement, après avoir bien débuté dans les années 60, la question de la conception logicielle connait son heure de gloire dans les années 70. les langages impératifs ont laissé la place à des langages dits procéduraux et structurés, basés sur la notion de procédures et de contrôle du flux. Les programmes sont plus simples à écrire, donc leurs capacités évoluent - ils deviennent plus imposants, plus difficiles à écrire, plus compliqués à maintenir. Il est urgent de dégager des règles qui permettent de définir comment programmer dans le but de limiter tous les problèmes liés à cette nouvelle façon d'écrire des programmes. On voit alors apparaître des contributions significatives (parmi lesquels une contribution de D.L. Parnas qui propose des critères objectifs pour découper les programmes en modules[1]. De ce découpage, il résulte une hiérarchie naturelle des différents modules, déjà mise en évidence par Ernst W. Dijkstra quelques années plus tôt).

De la décomposition en module - des unités fonctionnelle avec une cohésion certaine - on passe assez aisément à la décomposition en classes. Les recherches sur la programmation orientée objet décollent avec l'accélération du développement de Smalltalk[2] au milieu des années 70. Malgré une syntaxe qui n'est pas toujours très claire, le langage gagne en popularité lorsqu'il est distribué à large échelle dès le début des années 80. Encore une fois, on assiste à un bon dans l'évolution logicielle et il est nécessaire de faire évoluer la façon dont on les conçoit. Après 10 ans de pratique des technologies objet, on commence à voir apparaître des notions telles que les patrons de conception[3]. La technologie commence à être maîtrisée, le paradigme évolue. Il est temps de passer au niveau supérieur.

Qu'est-ce que l'architecture logicielle ?

Avant de répondre à cette question, sachez quand même que le vocable n'est pas si ancien - l'architecture logicielle est un domaine qui a été formalisé au début des années 90, avec l'apparition de systèmes d'information toujours plus gros et plus complexes à développer. Perry & Wolf, dans un article-manisfeste daté de 1992[4] définissent alors le rôle d'une branche d'étude qu'ils nomment architecure logicielle :

We use the term "architecture", in contrast to "design", to evoke notions of codification, of abstraction, of standards, of formal training (of software architects), and of style.

Traduction:

Nous utilisons le terme "architecture", en contraste à "conception", pour évoquer les notions de codification, d'abstraction, de standards, de formation (des architectes logiciels), et de style.

Au départ, tout découle d'une intuition : il existe un domaine appelé "architecture matérielle" qui se base sur un petit nombre de briques atomiques (les composants électroniques) pour aider à la conception d'ensembles plus importants (par exemple, mon iPhone) ; un autre s'appelle "architecture réseau" et se base sur des notions réduites de topologies ; et bien évidemment, il y a les architectes - les "vrais", ceux qui conçoivent des bâtiments en s'aidant de règles très définies, d'une connaissance aigüe des styles et de notations très formelles. Alors est-ce qu'une personne qui conçoit de bout en bout un système en se basant sur un grand nombre de petites briques (les composants logiciels) et en déterminant la topologie des relations entre ces composants ne serait pas lui aussi un architecte ?

Ne restait plus qu'à définir des règles (les principes d'architecture logicielle, ...), des notations formelles (UML, la grande espérances des ADL[5], ...) et de notions de style (préférer la composition à l'héritage, ...). La décennie des années 90 à 2000 fut particulièrement prolifique sur ce sujet - il suffit de taper la recherche "software+architecture" sur CiteSeer pour s'en convaincre.

En 2000, David Garlan a tenté de définir une route à suivre pour la décennie suivante[6]. Selon lui, l'architecture logicielle est le pont qui relie les exigences et l'implémentation. Elle a largement évolué pendant les années 90, passant d'une pratique empirique à quelque chose qui se rapproche plus d'un art (le résultat du travail d'un artisan, utilisant des techniques et des technologies reconnues). Il reconnait que le domaine est encore à un stade immature - il reste du travail a effectuer. Les modèles continuent d'évoluer, les scientifiques continuent de formaliser leur propositions sur le sujet. Mais on est encore loin d'une science qui pourra être apprise à grande échelle[7].

Conception contre architecture

Une fois ces deux notions examinée, il est plus aisé de voir les différences entre le design logiciel et l'architecture logicielle. Le premier s'attache a définir la structure d'un logiciel ; le second tente d'expliquer comment on peut définir cette structure. L'architecture logicielle est une généralisation de la conception logicielle, largement informelle.

Dès lors qu'on essaie de conceptualiser le design logiciel, on s'aventure dans le royaume de l'architecture logicielle. Le métier de l'architecte logiciel est de prendre en compte cette dimension formelle et conceptuelle et de l'utiliser pour concevoir logiciel (ou d'un système). Il peut alors soit rester à un niveau très haut (une description peu précise, qui sera alors affinée par d'autres architectes, puis par un développeur - qui pourra être obligé de faire une passe de conception), ou aller aussi loin que possible dans l'étude de l'architecture jusqu'à réaliser le design du logiciel nombre d'architectes logiciels sont aussi designers). L'architecte est donc au designer ce que le designer est au développeur. Il offre une vision qui est située un niveau d'abstraction plus haut que celle donnée par le designer.

Notes

[1] On the Criteria To Be Used in Decomposing Systems into Modules, D.L. Parnas, Communication of the ACM, 1972

[2] La premire version de Smalltalk, terminée en 1971, est largement influencée par Simula - le premier langage objet, qui lui date de 1967. Simula, bien que célèbre, n'a jamais eu énormément d'adeptes. C'est un langage majeur, qui introduit des concepts clefs tels que l'objet, le polymorphisme, les garbage collectors, et dans une certaine mesure, une dose de programmation fonctionnelle grâce à au passage des paramètres par nom

[3] Using Pattern Languages for Object-Oriented Programs, Kent Beck & Ward Cunningham, subimtted to OOPSLA'87, 1987

[4] Foundations for the Study of Software Architecture, Perry & Wolf, SOFTWARE ENGINEERING NOTES vol 17 no 4, ACM SIGSOFT Oct 1992

[5] Architecture Description Language ; des langages formels de description d'architecture. Ces langages formels ont été très à la mode pendant un temps, jusqu'à ce que quelqu'un s'aperçoive qu'écrire du méta-code qui permettait à une autre personne d'écrire du code était un brin plus complexe que dessiner 4 boites qui se courent après dans un modeleur graphique. Une évolution darwinienne s'il en est.

[6] Software Architecture: a Roadmap, Garlan, 2000 ; cette route à suivre est intéressante à plus d'un titre. Elle prévoit même (en 2000) l'avènement d'une approche centrée sur le réseau. Et que 10 ans plus tard, on appelle Cloud Computing.

[7] pour ma part, je pense que les scientifique qui travaillent sur le sujet font fausse route - ils tentent tout d'abord de dénombrer les différents types d'architecture, oubliant dans le processus qu'à chaque fois qu'une nouvelle technologie apparait, de nouveaux types d'architecture émergent. Leur travail est donc sans fin, mais ils est préliminaire à l'étude des architectures logicielles. On pourrait proposer une autre approche : étudier non pas les architectures logicielles mais l'architecture logicielle ; découvrir ce qui gouverne ce domaine - les règles, les principes, ... - ensuite, les différentes architectures existantes sont simplement dérivées de cette connaissance formalisée et de l'étude des systèmes.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet