Tâche: Incorporer les éléments de conception existants
Cette tâche décrit la manière de faire évoluer et d'affiner le modèle de conception.
Disciplines: Analyse et conception
Objet
  • Analyser les interactions de classes d'analyse afin de trouver des interfaces, des classes de conception et des sous-systèmes de conception
  • Affiner l'architecture, incorporer la réutilisation là où c'est possible.
  • Identifier les solutions communes à des problèmes de conception communément rencontrés
  • Inclure des éléments de modèle de conception significatifs d'un point de vue architectural dans la section Vue logique du document d'architecture logicielle.
Relations
Etapes
Identifier les opportunités de réutilisation
Objet Identifier les possibilités de réutilisation des sous-systèmes et/ou composants en fonction de leurs interfaces. 

Recherchez les sous-systèmes ou les composants existants offrant des interfaces similaires. Comparez chaque interface identifiée par rapport aux interfaces fournies par les sous-systèmes ou les composants existants. En règle générale, il n'y aura pas de correspondance exacte mais plutôt approximative. Recherchez tout d'abord les comportements similaires et les valeurs renvoyées, puis considérez les paramètres.

Modifiez les interfaces nouvellement identifiées afin d'améliorer les correspondances. Vous pouvez être amené à apporter des changements mineurs à une interface potentielle afin d'améliorer sa conformité vis-à-vis de l'interface existante. Des changements mineurs peuvent comprendre la réorganisation ou l'ajout de paramètres à l'interface potentielle, et ensuite la mise en facteur de l'interface en la scindant en plusieurs interfaces dont une ou plusieurs correspondront à celles du composant existant, avec les "nouveaux" comportements situés dans une interface séparée.

Remplacez les interfaces potentielles avec les interfaces existantes lorsqu'il existe des correspondances exactes. Après la simplification et la mise en facteur, s'il existe une correspondance exacte avec une interface existante, éliminez l'interface potentielle et utilisez simplement l'interface existante.

Mappez le sous-système potentiel aux composants existants. Recherchez les composants existants et l'ensemble des sous-systèmes potentiels. Mettez en facteur les sous-systèmes afin que les composants existants soient utilisés dès que cela est possible pour satisfaire aux exigences de comportement du système. Lorsqu'un sous-système potentiel peut être atteint par un composant existant, créez une traçabilité entre le sous-système de conception et le composant dans le modèle d'implémentation.

Lors du mappage de sous-systèmes à des composants réutilisables, considérez les mécanismes de conception associés au sous-système ; les exigences en matière de sécurité et de performance peuvent empêcher la réutilisation d'un composant même s'il existe une correspondance parfaite entre les signatures d'opération.

Bases de données et composants d'ingénierie inverse
Objet Incorporer des éléments de modèle potentiellement réutilisables à partir d'autres projets, de sources externes ou d'itérations antérieures. 

Le code existant et les définitions de base de données peuvent être 'récupérés' pour mettre à disposition de l'itération/projet en cours les opérations effectuées sur des projets ou itérations antérieurs. Le fait d'utiliser des possibilités de réutilisation potentielles comme filtre permet aux opérations auxquelles une ingénierie inverse a été appliquée de se concentrer uniquement sur les composants réutilisables pour l'itération en cours.

Appliquer une ingénierie inverse aux composants

Dans des organisations construisant des systèmes identiques, il existe souvent un ensemble de composants communs qui fournissent de nombreux mécanismes architecturaux nécessaires au nouveau système. Il est également possible qu'il existe des composants disponibles sur le marché susceptibles de fournir ces mécanismes architecturaux. Il est donc nécessaire d'examiner les composants existants afin de déterminer leur applicabilité et leur compatibilité avec l'architecture logicielle.

Les composants existants, qu'ils soient développés lors d'itérations antérieures mais pas encore inclus dans le modèle de conception, ou qu'il s'agisse de composants achetés, doivent subir une ingénierie inverse dans le modèle de conception. Dans le modèle de conception, de tels composants sont communément représentés comme un sous-système doté d'une ou plusieurs interfaces.

Appliquer une ingénierie inverse aux bases de données

Les bases de données et les données qu'elles contiennent représentent une des sources les plus importantes d'actifs réutilisables. Pour réutiliser des définitions de classe implicites intégrées dans des bases de données existantes, déterminez quelles sont les informations utilisées par l'application qui résident déjà dans les bases de données existantes. Effectuez une ingénierie inverse sur un ensemble de classes représentant les structures de la base de données qui détiennent ces informations. Parallèlement, effectuez un mappage entre la représentation de la classe d'application et les structures utilisées dans la base de données. Pour plus d'informations sur l'application d'une ingénierie inverse aux bases de données, voir Instructions relatives au produit : Appliquer une ingénierie inverse aux bases de données relationnelles. Pour plus d'informations sur le mappage entre les classes et les tables d'une base de données relationnelle, voir Instructions relatives au produit : Modèle de données.

Mettre à jour l'organisation du modèle de conception
Objet Prendre en compte les nouveaux éléments du modèle dans l'organisation du modèle de conception.
Rééquilibrer la structure du modèle de conception si nécessaire. 

Lorsque de nouveaux éléments ont été ajoutés au modèle de conception, le regroupement des éléments du modèle de conception est souvent nécessaire. Le regroupement permet d'atteindre différents objectifs : il réduit le couplage entre les packages et améliore la cohésion au sein des packages dans le modèle de conception. Le but ultime étant de permettre aux différents packages (et sous-systèmes) d'être conçus et développés indépendamment les uns des autres par des personnes séparées ou des équipes. Même si une indépendance complète est probablement impossible à atteindre, un couplage souple entre les packages tend à améliorer le développement des systèmes complexes et de grande envergure.

Une structure de modèle 'plate' (où tous les packages et sous-systèmes résident au même niveau conceptuel dans le système) convient à un petit système ; les systèmes plus volumineux nécessitant un outil de structuration supplémentaire appelé 'outil d'organisation en couches' (voir Instructions relatives au produit : Organisation en couches). Les règles d'organisation en couches définissent des restrictions sur des relations autorisées entre certains types de packages. Ces règles prennent en compte le fait que certaines dépendances ne devraient pas exister : la fonctionnalité de l'application ne doit pas être directement dépendante de services spécifiques relatifs au système d'exploitation ou au système de fenêtrage - il doit exister une couche intermédiaire contenant des services logiques de système d'exploitation et de fenêtrage qui isolent la fonctionnalité de l'application de changements effectués dans les services d'implémentation de bas niveau. L'organisation en couches permet de réduire l'impact des changements : en mettant en place des règles qui restreignent les dépendances entre les packages et les sous-systèmes, réduisant ainsi le degré de couplage entre les packages et les sous-systèmes, le système devient plus robuste. Il tolère les changements.

Au fur et à mesure que les éléments de modèle sont ajoutés au système, il est possible que les packages existants soient trop grands pour être gérés par une seule équipe : le package doit être scindé en différents packages avec un couplage souple entre les packages. Cela peut s'avérer difficile - certains éléments peuvent être compliqués à placer dans un package spécifique dans la mesure où ils sont utilisés par des éléments des deux packages. Il existe deux solutions possibles : scinder l'élément en différents objets, un dans chaque package (cela fonctionne lorsque l'élément a différentes 'personnalités' ou des ensembles de personnalités disjointes), ou déplacer l'élément vers un package dans une couche inférieure, où tous les éléments de la couche supérieure en dépendront de manière égale.

Au fur et à mesure que le système gagne en complexité, un grand nombre de couches sera nécessaire pour obtenir une structure gérable et compréhensible. Cependant, même dans les grands systèmes, il est rare d'avoir plus de 7 à 10 couches dans la mesure où la complexité s'accroît et la compréhensibilité diminue avec le nombre de couches.

Ci-dessous figure un exemple d'organisation en couches, comprenant des couches logicielles système et intermédiaires :

Diagramme de présentation d'une application Java/Web

Exemple d'organisation en couches d'un package pour une application Java/Web. Remarque : les dépendances sur le package TCP/IP ne seraient normalement pas explicitement modélisées dans la mesure où l'utilisation de services TCP/IP est encapsulée au sein de la machine virtuelle Java, java.rmi et le navigateur Web. Les descriptions de cet exemple ne sont fournies qu'à titre d'illustration.

Affectation de responsabilités pour les sous-systèmes et les couches à des personnes ou des équipes. Chaque package ou sous-système doit être la responsabilité d'une personne (si sa portée est petite) ou d'une équipe (si sa portée est grande).

Mettre à jour la vue logique
Objet S'assurer que le Produit : Document d'architecture logicielle (vue logique) reste à jour. 

Lorsque les classes de conception, les packages et les sous-systèmes (éléments du modèle) sont importants d'un point de vue architectural, il doivent être inclus dans la section Vue logique du Produit : Document d'architecture logicielle. Cela garantira que les nouveaux éléments significatifs du point de vue de l'architecture seront communiqués aux autres membres du projet.

En outre, l'architecte logiciel collabore avec le responsable de processus pour fournir des instructions détaillées aux concepteurs et implémenteurs concernant la manière d'utiliser les éléments de conception nouvellement intégrés.



Plus d'informations