Activité :
|
Objet
|
|
Rôle : Architecte logiciel | |
Fréquence : Une fois par itération | |
Etapes | |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : |
Détails sur l'enchaînement d'activités : |
Objet | Identifier les cas où les sous-systèmes et/ou les autres composants existants peuvent être réutilisés sur la base de leurs interfaces. |
Recherchez les sous-systèmes ou les composants existants offrant des interfaces similaires. Comparez chaque interface identifiée aux interfaces fournies par les sous-systèmes ou composants existants. Les correspondances entre elles ne seront peut-être pas exactes, mais vous trouverez des correspondances approximatives. Recherchez tout d'abord les comportements et valeurs renvoyées similaires, puis les paramètres.
Modifiez les interfaces que vous venez d'identifier pour améliorer l'adéquation. Vous pouvez être amené à apporter des modifications mineures à une interface potentielle afin d'améliorer sa conformité vis-à-vis de l'interface existante. Ces modifications peuvent inclure la réorganisation ou l'ajout de paramètres à l'interface potentielle, la division en plusieurs interfaces (une ou plusieurs d'entre elles correspondant à celles du composant existant), les "nouveaux" comportements se trouvant au sein d'une interface séparée.
Remplacez les interfaces potentielles par les interfaces existantes en cas de correspondance totale. Une fois ces opérations effectuées, s'il existe une correspondance parfaite avec une interface existante, éliminez l'interface potentielle et utilisez simplement l'interface existante.
Mappez le sous-système candidat aux composants existants. Recherchez les composants existants et l'ensemble de sous-systèmes potentiels. Adaptez les sous-systèmes de telle sorte que les composants existants soient utilisés le plus souvent possible pour se conformer au comportement requis du système. Lorsqu'un sous-système potentiel peut être réalisé par un composant existant, créez une traçabilité entre le sous-système de conception et le composant figurant dans le modèle d'implémentation.
Lorsque vous mappez des sous-systèmes à des composants réutilisables, tenez compte des mécanismes de conception associés au sous-système ; les performances ou la sécurité risquent d'empêcher la réutilisation d'un composant en dépit d'une correspondance parfaite entre les signatures des opération.
Objet | Incorporer des éléments de modèles potentiellement réutilisables en provenance 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 assimilés pour que le travail effectué lors de projets ou d'itérations antérieures soit disponible pour le projet/l'itération en cours. En utilisant les opportunités de réutilisation potentielles comme filtre, le travail objet d'une génération de code peut se concentrer sur les composants réutilisables pour l'itération en cours.
Dans les organisations qui élaborent ce type de système, il existe souvent un ensemble de composants qui offrent une bonne partie des mécanismes architecturaux requis pour les nouveaux systèmes. Par ailleurs, certains composants disponibles sur le marché peuvent offrir ces mécanismes architecturaux. Les composants existants doivent être examinés afin de déterminer leur adéquation et leur compatibilité au sein de l'architecture logicielle.
Les composants existants (développés au cours d'itérations antérieures mais ne figurant pas encore dans le modèle de conception, ou encore achetés) doivent faire l'objet d'une génération de code et être incorporés dans le modèle de conception. Dans ce modèle, ces composants sont généralement représentés sous forme de sous-système incluant une ou plusieurs interfaces.
Les bases de données, et les données qu'elles contiennent, représentent l'une des sources les plus importantes de ressources réutilisables. Pour réutiliser les définitions de classes implicites incorporées aux bases de données existantes, déterminez, parmi les informations utilisées par l'application, celles qui résident déjà dans les bases de données existantes. Effectuez une génération de code sur un ensemble de classes afin de faire ressortir les structures de base de données contenant ces informations. Simultanément, mappez la représentation de classes de l'application aux structures utilisées dans la base de données.
Pour plus d'informations sur les bases de données de génération de code, voir les Principes et conseils sur les bases de données relationnelles de génération de code. Pour plus d'informations sur les mappages entre les classes et les tables des bases de données relationnelles, voir les Principes et conseils sur le modèle de données.
Objet | Incorporer de nouveaux éléments de modèle à l'organisation du modèle de conception. Rééquilibrer la structure du modèle de conception, le cas échéant. |
Au fur et à mesure que de nouveaux éléments sont ajoutés au modèle de conception, un nouveau package des différents éléments du modèle de conception s'avère souvent nécessaire. Ce nouveau package a plusieurs objectifs : il diminue les couplages entre les packages et il améliore la cohésion entre les différents packages du modèle de conception. L'objectif final consiste à autoriser différentes personnes ou équipes à concevoir et à développer des packages (et des sous-systèmes) indépendants les uns des autres. Une complète indépendance est sans doute impossible à atteindre, mais un couplage limité entre les packages tend à faciliter le développement de gros systèmes ou de systèmes complexes.
Une structure de modèle plate (dans laquelle tous les packages et sous-systèmes résident sur le même niveau conceptuel du système) est adaptée aux petits systèmes. Les gros systèmes, en revanche, doivent utiliser un outil supplémentaire d'organisation en couches (voir les Principes et conseils sur la gestion des couches). Les règles d'organisation en couches définissent les limitations applicables aux relations entre certains types de packages. Ces règles spécifient que certaines dépendances ne doivent pas exister : les fonctionnalités d'applications ne doivent pas dépendre directement d'un système d'exploitation spécifique ou des services système interfenêtre : une couche intermédiaire doit exister (cette couche contient le système d'exploitation logique et les services système interfenêtre qui isolent les fonctionnalités d'applications des modifications apportées aux services d'implémentation de niveau inférieur. L'organisation en couches permet de diminuer l'impact des modifications apportées : grâce à la mise en application des règles qui limitent les dépendances entre les packages et les sous-systèmes et à la diminution du niveau de couplage entre les packages et les sous-système, le système devient plus robuste. Il tolère les changements.
Lorsque de nouveaux éléments de modèle sont ajoutés au système, les packages existants peuvent croître démesurément et devenir difficiles à gérer par une seule équipe : le package doit dans ce cas être divisé en plusieurs packages cohérents mais peu couplés. Cette opération peut être difficile (certains éléments peuvent être difficiles à placer dans un package spécifique car ils sont utilisés par les éléments des deux packages). Deux solutions existent. Vous pouvez diviser l'élément en plusieurs objets (un dans chaque package) ; cela fonctionne bien lorsque l'élément a plusieurs 'personnalités' ou ensembles de responsabilités distinctes. Vous pouvez également déplacer l'élément dans un package situé sur une couche inférieure, au sein de laquelle tous les éléments peuvent être dépendants de façon égale.
Le système devient de plus en plus complexe ; un plus grand nombre de couches est alors requis pour que la structure soit gérable et compréhensible. Toutefois, il est rare de rencontrer plus de 7 à 10 couches, même sur les plus gros systèmes, car la complexité augmente et l'intelligibilité diminue au fur et à mesure que le nombre de couches augmente.
Voici un exemple d'organisation en couches incluant des couches de logiciels standard personnalisés et de logiciels système :
Exemple d'organisation en couches de packages pour une application Java/Web. Remarque : normalement, les dépendances au niveau du package TCP/IP ne sont pas explicitement modélisées car l'utilisation des services TCP/IP est encapsulée dans Java VM, java.rmi et dans le navigateur Web. Elles sont représentées ici à des fins d'illustration uniquement.
Affectez les responsabilités des sous-systèmes et des couches aux personnes ou aux équipes. La responsabilité de chaque package ou sous-système doit être confiée à une seule personne (si l'étendue n'est pas trop vaste) ou à une équipe (dans le cas contraire).
Objet | S'assurer que l'artefact du document d'architecture logicielle (vue logique) est à jour. |
Lorsque des classes de conception, des packages et des sous-systèmes (éléments de modèle) sont importants d'un point de vue architectural, ils doivent être inclus dans la section consacrée à la vue logique de l'artefact du document d'architecture logicielle. Cela permet de s'assurer que les nouveaux éléments de modèle importants sur le plan architectural sont communiqués aux autres membres de l'équipe projet.
En outre, le rôle architecte du logiciel collabore avec le rôle responsable de processus pour fournir aux concepteurs et aux implémenteurs des instructions détaillées sur l'utilisation des éléments de conception incorporés.
RUP (Rational Unified Process)
|