đŸ‘¶ FERMETURE : L'Atelier est fermĂ© jusqu'au 29 aoĂ»t en raison d'un congĂ© paternitĂ©. đŸ‘¶

Designing Software for Ease of Extension and Contraction

✒ Enzo SandrĂ© · 📆 22/11/2021 · 📜 Lois du dĂ©veloppement · #ïžâƒŁ Façonnage de code · 📐 Architecture

👮 Je continue de dĂ©couvrir l’immense David Parnas, au travers d’un second article, sur la maniĂšre de concevoir des logiciels afin qu’ils soient facile Ă  Ă©tendre et Ă  rĂ©duire selon les impĂ©ratifs client. Il date de 1979, c’est l’information la plus dingue vu l’actualitĂ© du papier.

RĂšgles de design

📜 Parnas donne 4 rùgles permettant de garder une grande souplesse dans le design des logiciels :

1ïžâƒŁ Commencer par un monolithe. CrĂ©er un module Ă  chaque dĂ©cision de design importante afin d’encapsuler cette dĂ©cision et de rendre facile le changement si elle s’avĂ©rait peu judicieuse.

2ïžâƒŁ Lister les Ă©lĂ©ments qui sont susceptibles de changer. S’assurer qu’ils sont absents des interfaces des modules que l’on conçoit.

3ïžâƒŁ Ne pas subdiviser son programmes en Ă©tapes d’un traitement. PrivilĂ©gier la conception par « machines virtuelles », oĂč chaque module masque la complexitĂ© de la couche infĂ©rieure en ne laissant filtrer que ce qui est utile Ă  des tĂąches plus Ă©levĂ©es.

4ïžâƒŁ Ne crĂ©er de dĂ©pendances que si elles sont utiles. Parnas entend par lĂ  que :
1) A est plus simple parce qu’il utilise B.
2) B n’est pas plus complexe si A l’utilise.
3) Il existe un programme utile incluant B, mais pas A
4) Il n’y a aucun programme utile contenant A, mais pas B.

Coûts de fonctionnement et de changement

đŸ’» Nous connaissons tous la dynamique qui lie mĂ©moire et CPU, de sorte que toute optimisation de l’un coĂ»te de l’autre.
Le mĂȘme type de relation existe entre coĂ»t de fonctionnement et coĂ»t du changement. Je reviens sur le papier de Parnas postĂ© il y a une semaine, car il rĂ©vĂšle des trĂ©sors nouveaux Ă  chaque lecture.

📏 Un logiciel gĂ©nĂ©rique diffĂšre d’un logiciel flexible. Le premier rĂ©pond Ă  plusieurs cas d’usage sans changement, alors que le second ne rĂ©pond qu’à un cas d’usage mais peut ĂȘtre facilement adaptĂ© pour en couvrir d’autres.

👉 La gĂ©nĂ©ricitĂ© a un surcoĂ»t de fonctionnement (le logiciel est forcĂ©ment plus gros), mais un coĂ»t de changement nul.

👉 La flexibilitĂ© a n’a aucun surcoĂ»t de fonctionnement, mais possĂšde un coĂ»t de changement dĂ©pendant de la qualitĂ© de l’implĂ©mentation.
💰 Le choix entre gĂ©nĂ©ricitĂ© et flexibilitĂ© est (normalement) purement stratĂ©gique et Ă©conomique. Ce qu’un logiciel gagne d’un cĂŽtĂ© il le perd de l’autre. C’est une consĂ©quence probablement indĂ©passable de la VIIIĂšme loi de Lehman : dans ce complexe d’interactions homme-machine, tout est gouvernĂ© par des boucles de rĂ©troaction.

SOURCE

Parnas, David. (1979). Designing Software for Ease of Extension and Contraction. Software Engineering, IEEE Transactions on. SE-5. 128- 138. 10.1109/TSE.1979.234169.

Enzo Sandré


DOIs: 10.1109/TSE.1979.234169