Une architecture de référence est, en essence, un pattern ou un ensemble de schémas d'architecture prédéfinis, instanciés partiellement ou totalement, conçus et confirmés pour utilisation dans des contextes métier et techniques donnés, de pair avec des artefacts de support permettant leur utilisation. Souvent, ces artefacts sont extraits de projets antérieurs. 
Rôle :  Architecte logiciel 
Caractère facultatif/Occurrence:  Facultatif. Phases de création et d'élaboration.
Canevas et rapports: 
     
Exemples : 
     
Représentation UML :  Diverses vues d'architecture pertinentes : cas d'utilisation, logique, processus, déploiement, implémentation, données.
Informations supplémentaires :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

Les artefacts de l'architecture de référence font partie de la base de ressources réutilisables d'une organisation. Leur objet est de fournir un point de départ pour le développement de l'architecture. Ils peuvent être constitués de schémas d'architecture, de mécanismes d'architecture et de structures, et jusqu'à des systèmes complets, avec des caractéristiques connues et à usage avéré. Ils peuvent s'appliquer en général, ou pour une large classe de systèmes recouvrant plusieurs domaines ou bien avoir une portée plus étroite, spécifique à un domaine.

L'utilisation d'architectures de référence confirmées est un moyen efficace d'aborder les exigences non fonctionnelles, notamment les exigences de qualité, par la sélection d'architectures de référence existantes dont l'usage a confirmé qu'elles répondent à ces exigences. Les architectures de référence peuvent exister ou être utilisées à différents niveaux d'abstraction et depuis des perspectives diverses. Elles correspondent aux vues 4+1 (voir "Ensemble typique de vues d'architecture"). De cette manière, l'architecte logiciel peut sélectionner ce qui convient le mieux : conception de l'architecture seulement ou conception et implémentation, à divers niveaux d'achèvement. 

Souvent, une architecture de référence est définie de sorte à ne pas inclure d'instances des composants qui seront utilisés pour construire le système et ce, afin qu'elle ne devienne pas elle-même une Architecture de ligne de produits, mais cette distinction n'est pas difficile, ni rapide à établir. Dans RUP (Rational Unified Process (RUP), nous permettons à la notion d'architecture de référence d'inclure des références à des éléments existants, réutilisables (c'est-à-dire à des implémentations).

Bref aperçu Haut de la page

Organisation des ressources

L'organisation propriétaire des ressources de l'architecture de référence doit décider lesquelles seront classifiées et organisées pour leur extraction facile par l'architecte logiciel, en mettant en correspondance les critères de sélection pour le nouveau système. Bien que la création et le stockage des architectures de référence soient actuellement hors du champ d'action de RUP, nous pouvons toutefois suggérer d'organiser les architectures autour du concept de domaines, (où un domaine définit des connaissances et des concepts sur un certain aspect du système ou d'une famille de systèmes). Nous autorisons ici l'utilisation du terme 'domaine' à des niveaux au-dessous de celui de l'application. Cet usage diffère légèrement de certaines définitions, par exemple celle représentée dans [HOF99], mais se plie bien à celle décrite dans [LMFS96]:

"Domaine de ligne de produits: groupe délimité de capacités, présentes et/ou futures, définies en vue de faciliter la communication, l'analyse et l'ingénierie afin d'identifier, de construire et de gérer les similitudes à travers une ligne de produits. Ces domaines peuvent englober des groupes étroitement associés de systèmes d'utilisateur final, de fonctions communes à des systèmes multiples, ou des regroupements de services sous-jacents à application très répandue."

Cette définition repose sur la notion que des éléments utilisés pour composer un système peuvent appartenir eux-mêmes à un domaine méritant sa propre étude. La figure ci-dessous, empruntée de [LMFS96], illustre ce principe.

Domaines horizontaux et verticaux dans l'Armée des Etats-Unis

Domaines horizontaux et verticaux pour l'Armée des Etats-Unis

Cette figure présente les principales familles de systèmes (systèmes d'information, systèmes de commandement et de contrôle, systèmes d'armements), certains contenant des domaines verticaux entiers, et des domaines horizontaux transversaux à ces systèmes et à d'autre familles de systèmes. Par conséquent, les concepts de planification en temps réel s'appliquent au domaine tactique du commandement et contrôle et à tous les domaines verticaux des systèmes d'armement. Il est donc raisonnable de résoudre une fois pour toutes l'ensemble des problèmes de planification en temps réel pour tous ces domaines, et de considérer les connaissances et ressources ainsi développées comme un domaine distinct qui aura ensuite une association avec, par exemple, la guerre électronique mains non pas avec les systèmes d'informations sur le personnel.

Contenu

L'architecture de référence a la même forme que l'Artefact : Document d'architecture logicielle et ses modèles associés, dépouillé des références spécifiques au projet ou doté de références et de caractéristiques de projet génériques, afin que cette architecture puisse être convenablement classifiée dans la base des ressources. Les modèles habituellement associés au document d'architecture logicielle comprennent les modèles de cas d'utilisation, de conception, d'implémentation et de déploiement.

L'accès au document d'architecture logicielle et à ses modèles associés procure plusieurs points d'entrée à l'architecte logiciel, qui peut alors choisir de n'utiliser que les éléments conceptuels ou logiques de cette architecture (dans la mesure où les pratiques de réutilisation de l'organisation le permettent). A l'autre extrême, l'architecte logiciel peut prélever de la base de ressources des sous-systèmes fonctionnels complets, et un modèle de déploiement au niveau physique (c'est-à-dire, un plan complet du matériel et du réseau).

D'autres artefacts de support sont requis pour permettre l'utilisation des ressources d'architecture. 

  1. Le modèle de cas d'utilisation décrit le comportement de l'architecture mais l'architecte logiciel doit aussi connaître ses caractéristiques non fonctionnelles. Ces deux aspects (modèle de cas d'utilisation et exigences non fonctionnelles) peuvent déjà avoir été recensés dans une spécification des exigences logicielles. L'architecte logiciel pourra alors déterminer à partir de ce document à quel point l'architecture de référence se conforme aux exigences actuelles.

  2. L'utilisation, et plus spécialement la modification de l'architecture, devra se référer aux lignes directrices ayant piloté le développement originel. L'architecte logiciel devra, par exemple, savoir quelles règles ont été appliquées à la formation de l'architecture de référence et déterminer la difficulté à modifier les interfaces. L'accès aux principes de conception associés à l'architecture de référence peut aider à répondre à ces questions.

  3. (Facultatif) L'examen des plans de test existants pertinents peut aussi avoir son utilité. Ces plans de test peuvent renseigner l'architecte du test sur les stratégies de test et d'évaluation antérieures utilisées pour tester des architectures similaires, et qui en tant que telles sont susceptibles de fournir des indications sur les faiblesses potentielles de l'architecture.

  4. (Facultatif) L'examen d'architectures d'automatisation de test et de spécifications d'interface de test existantes et pertinentes peut aussi être judicieux . Ces artefacts informent l'architecte des requêtes probables sur l'architecture afin de faciliter les tests.

Calendrier Haut de la page

L'architecture de référence est utilisée au cours de la phase de création et au début de l'élaboration lors de la synthèse de l'architecture et de la sélection d'une architecture potentielle. La création d'architectures de référence est du ressort de l'organisation et hors du cadre actuel de RUP. Lors de la clôture du projet, les artefacts créés au cours de celui-ci devront être examinés afin de déterminer si des éléments peuvent être collectés et conservés dans la base de ressources de l'organisation, bien que les activités et les techniques employées à cet effet ne soient pas détaillées ici.

Responsabilité Haut de la page

L'architecte logiciel est responsable de la sélection et de l'usage des architectures de référence.

Personnalisation Haut de la page

A moins que le système n'ait aucun précédent, les architectures de référence doivent être examinées pour déterminer leur applicabilité (pour le domaine et le type de développement concernés) dans la mesure où elles existent et sont accessibles à l'organisation de développement. La création d'architectures de références est une question qui doit être abordée au niveau de l'organisation. Il est certainement possible de condenser la liste des contenus ci-dessus tout en conservant certains avantages de la réutilisation d'une architecture. Il est possible, par exemple, d'omettre le modèle de test, bien que les tests devraient alors être rédigés à nouveau en cas de modification de l'architecture. Au minimum, cette liste devrait inclure un modèle de conception et une description du comportement associé (éventuellement le modèle de cas d'utilisation). En dessous de cette limite, cette ressource peut difficilement constituer une architecture de référence bien qu'elle puisse encore fournir un pattern valide (analyse, conception, ...).



RUP (Rational Unified Process)   2003.06.15