articulent les décisions de conception qui déterminent les propriétés comportementales et structurelles primaires d’un programme (système logiciel). Les décisions stratégiques traitent des préoccupations globales, à l’échelle du système, et portent les implications les plus conséquentes. Les décisions stratégiques comprennent le choix du paradigme de programmation (« programmation orientée objet »), du style architectural (« tuyaux et filtres »), du cadre d’application (« Microsoft Foundation Classes »), des normes d’ingénierie logicielle basées sur les composants (« Enterprise JavaBeans ») et des principes de conception (« classe de base universelle »), ainsi que des hypothèses susceptibles d’entraîner une inadéquation architecturale (« Le serveur de messages de diffusion Softbench s’attendait à ce que tous les composants aient une interface utilisateur graphique ») et des régularités régies par des lois (« chaque classe du système hérite de la classe C »). En raison des conséquences qu’elles entraînent, les décisions stratégiques doivent être prises tôt dans le processus de développement du logiciel et doivent être établies explicitement avant toute conception détaillée.
En revanche, les déclarations de conception tactique articulent les décisions de conception qui concernent un module spécifique. Les décisions tactiques décrivent souvent un modèle de corrélations entre une collection de modules (objets, procédures, classes, etc.) et une autre. Intuitivement, les déclarations tactiques sont « locales » dans le sens où leur portée est limitée à une partie du programme et non à l’extérieur. Les décisions tactiques comprennent le choix des patrons de conception (‘Factory Method’), les remaniements (‘Replace Conditional With Polymorphism’), et les idiomes de programmation (‘counted pointer’), et sont généralement prises beaucoup plus tard que les décisions de conception stratégiques dans le processus de développement du logiciel.
Bien que je sois largement d’accord avec la règle générale de global = stratégique et local = tactique, elle ne doit pas être considérée comme un absolu. Il est possible qu’un segment d’un système ait des aspects qui influencent fortement l’architecture globale (justifiant les critères d’importance de Booch). C’est la raison pour laquelle je ne suis pas d’avis que les exigences fonctionnelles relèvent du design et les non-fonctionnelles de l’architecture.
Arnon Rotem-Gal-Oz, responsable de l’architecture chez Nice Systems, identifie plusieurs aspects de l’architecture dans sa présentation « Software Architecture ». L’architecture comprend les principaux composants d’un système ; leurs relations et leurs interactions. Les données et le comportement de ces composants majeurs ne sont pertinents pour l’architecture que du point de vue des interactions entre ces composants. Comme Booch, Rotem-Gal-Oz caractérise l’architecture comme étant la partie du système la plus difficile à modifier. Comme Eden, Kazman et Hirshfeld, il définit l’architecture comme les décisions de conception qui doivent être prises le plus tôt dans le processus.
La valeur des décisions de conception stratégiques et fondatrices devrait être évidente. Comme ces aspects du système sont à la fois difficiles et coûteux à modifier, il devrait y avoir une incitation considérable à faire des choix optimaux. Comme le note Kevlin Henney dans « What is Software Architecture ? » sur developerFusion:
La question n’est pas de savoir si un système a une architecture ou non, mais si son architecture est bonne ou non. Tous les systèmes ont une architecture, qu’elle soit intentionnelle ou accidentelle, explicite ou implicite, bonne ou mauvaise – même les systèmes « sans architecture » ont une architecture !
Ayant relié l’architecture au coût du changement, nous avons un moyen simple d’évaluer la qualité de l’architecture. Ce n’est pas qu’une bonne architecture rende un système bon marché à créer ; c’est qu’elle est aussi bon marché à faire évoluer. En d’autres termes, une bonne architecture est une architecture dans laquelle l’importance des décisions de conception est minimisée. Vous êtes libre de modifier de nombreux aspects d’un système sans craindre que ces changements soient difficiles, coûteux ou créent une cascade de bogues. Une bonne architecture est donc une architecture durable.
Compte tenu de la criticité de ces décisions de conception, il est peu judicieux de les laisser au hasard. Il est peu probable qu’une architecture durable et flexible émerge de manière organique. Une planification et une coordination suffisantes seront nécessaires de la part d’une personne ayant le rôle d’architecte (que ce rôle soit à temps plein ou à temps partiel). Les décisions de conception localisées peuvent ensuite être prises dans ce cadre de manière décentralisée.
De temps en temps, j’entends des gens soulever encore le mantra agile contre la grande conception/les exigences en amont. La chose est que le Manifeste Agile n’a jamais dit d’enfouir intentionnellement votre tête dans le sable en ce qui concerne le but du système. Il s’agissait d’une réaction contre le fait de passer des mois en analyse sans que rien d’autre que des documents n’en sortent, mais le but était de trouver un terrain d’entente. Personne n’a jamais dit « pas de conception en amont » ou « pas d’exigences en amont ».
(Udi Dahan de « A CQRS Journey – with and without Microsoft »)
Reposted from Form Follows Function
.