6.1 Décomposition
Malgré la variété des critères, la tâche principale dans le développement de grands systèmes est la tâche de réduire la complexité du système . Pour réduire la complexité, rien d'autre que la division en parties n'a encore été inventé.
Parfois, pour simplifier, on appelle cela le principe de "diviser pour mieux régner", mais, du point de vue de l'architecte logiciel, on parle de décomposition hiérarchique .
Un système complexe doit être construit à partir d'un petit nombre de sous-systèmes plus simples, dont chacun, à son tour, est construit à partir de parties plus petites, et ainsi de suite jusqu'à ce que les plus petites parties soient suffisamment simples pour être directement comprises et créées.
La bonne nouvelle est que cette solution est non seulement la seule connue, mais aussi universelle. En plus de réduire la complexité, il fournit simultanément la flexibilité du système , une bonne évolutivité et une résilience accrue en dupliquant les parties critiques.
Ainsi, lorsqu'il s'agit de construire l'architecture du programme, de créer sa structure, cela revient à décomposer le programme en sous-systèmes, services, couches, sous-programmes et modules fonctionnels et à organiser leur interaction entre eux et avec le monde extérieur.
Et la chose la plus précieuse ici est la suivante : plus les sous-systèmes sont indépendants, plus il est sûr de se concentrer sur le développement de chacun d'eux séparément à un moment donné et de ne pas se soucier de toutes les autres parties.
6.2 Avantages de l'architecture modulaire
L'utilisation du principe de décomposition hiérarchique vous permet de vous débarrasser du chaos dans des milliers de classes de votre code. N'oubliez pas que votre code est divisé en packages (package) et sous-packages ? C'est l'une des expressions de la décomposition hiérarchique.
Votre programme se transforme d'un ensemble de classes en un ensemble de bibliothèques et de modules qui interagissent les uns avec les autres selon des règles bien définies et simples. Ceci, à son tour, vous permet de contrôler sa complexité et vous donne également la possibilité d'obtenir tous les avantages généralement associés au concept d'une bonne architecture.
Voici les plus basiques :
- Évolutivité - la possibilité d'étendre le système et d'augmenter ses performances en ajoutant de nouveaux modules.
- Maintenabilité - changer un module ne nécessite pas de changer d'autres modules.
- Interchangeabilité des modules (Swappability) - le module peut être facilement remplacé par un autre.
- Test unitaire – Une unité peut être détachée de toutes les autres et testée/réparée .
- Réutilisabilité - le module peut être réutilisé dans d'autres programmes et d'autres environnements.
- Maintenance - un programme divisé en modules est plus facile à comprendre et à entretenir.
On peut dire que briser un problème complexe en fragments simples est le but de toutes les techniques de conception . Et le terme "architecture" dans la plupart des cas fait simplement référence au résultat d'une telle division plus "certaines décisions de conception qui, une fois adoptées, sont difficiles à changer" (Martin Fowler "Architecture of Enterprise Software Applications").
Par conséquent, la plupart des définitions sous une forme ou une autre se résument à ce qui suit :
" L'architecture identifie les principaux composants du système et la façon dont ils interagissent. C'est aussi le choix de telles décisions qui sont interprétées comme fondamentales et non sujettes à changement dans le futur ".
« L'architecture est l'organisation d'un système, matérialisée par ses composants, leurs relations entre eux et avec l'environnement. Un système est un ensemble de composants combinés pour remplir une fonction spécifique .
Ainsi, une bonne architecture est avant tout une architecture modulaire/bloc . Pour obtenir une bonne architecture, il faut savoir décomposer correctement le système. Cela signifie qu'il est nécessaire de comprendre quelle décomposition est considérée comme «correcte» et comment il est préférable de la réaliser.