Produit: Architecture de référence
Ce produit est, par essence, un pattern d'architecture prédéfini, ou un ensemble de patterns, qui peut être instancié de manière partielle ou en totalité, conçu pour être utilisé dans certains contextes métier et techniques et y ayant fait ses preuves, associé à des artefacts de prise en charge permettant de l'utiliser.
Objet

Les produits de l'architecture de référence font partie de la base d'actifs réutilisables de l'organisation. Leur objectif est de créer un point de départ pour le développement de l'architecture. Il peut s'agir de patterns d'architecture, de mécanismes d'architecture et d'infrastructure préfabriquée déjà constitués qui permettent de compléter des systèmes, possèdent des caractéristiques connues et dont l'efficacité a été prouvée. Ils peuvent être applicables de façon générique ou pour une large classe de domaines traversant des systèmes, ou encore avoir une cible plus étroite, spécifique à un domaine.

L'utilisation d'architectures de référence déjà testées est un moyen efficace de répondre à nombre d'exigences non fonctionnelles, notamment aux exigences de qualité, puisqu'il a été prouvé qu'elles satisfont effectivement à ces exigences. Les architectures de référence peuvent exister ou être utilisées à différents niveaux d'abstraction et selon différents points de vue. Ces derniers correspondent aux vues 4+1 (voir "Ensemble typique de vues d'architecture"). De cette façon, l'architecte logiciel est en mesure de choisir ce qui convient le mieux : uniquement la conception de l'architecture ou la conception couplée à l'implémentation, à différents degrés d'exécution. 

Une architecture de référence est souvent définie de façon à ne pas inclure d'instances des composants qui seront utilisés pour construire le système (dans le cas contraire, elle devient une architecture de gamme de produits), mais cette distinction n'a pas un caractère absolu. Dans RUP, la notion d'architecture de référence peut inclure des références à des composants réutilisables existants (c'est-à-dire à des implémentations).

Relations
RôlesResponsable: Modifié par:
Entrée versObligatoire: Facultatif:
  • Aucun
Externe:
  • Aucun
Description
Bref aperçu

Organisation des actifs

L'organisation qui possède les actifs d'architecture de référence devra déterminer la façon dont ces actifs seront classés et organisés afin d'en faciliter la récupération par l'architecte logiciel, en faisant correspondre 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 n'entrent pas actuellement dans la portée de RUP, il est possible d'organiser les architectures autour de l'idée de domaines, selon laquelle un domaine définit les connaissances et concepts relatifs à un aspect d'un système ou à une famille de systèmes. Nous autorisons ici l'utilisation du terme "domaine" à des niveaux inférieurs à celui de l'application. Dans ce sens, il diffère légèrement de certaines définitions (par exemple, celle présentée dans [HOF99]), mais correspond bien à celle présentée dans [LMFS96] :

"Domaine de gamme de produits : ensemble borné de fonctions (présentes et/ou futures) défini pour faciliter la communication, l'analyse et l'ingénierie afin d'identifier, de concevoir et de gérer la banalisation sur une gamme de produits. Ce type de domaine peut inclure des groupes étroitement liés de systèmes d'utilisateurs finals, des fonctions couramment utilisées sur des systèmes multiples ou des regroupements à application très large de services sous-jacents."

Cette définition signifie que les éléments utilisés pour composer des systèmes peuvent également appartenir à un domaine qu'il est intéressant d'étudier pour lui-même. La figure ci-dessous, extraite de [LMFS96], illustre ce principe.

Domaines horizontaux et verticaux de l'armée américaine

Domaines horizontaux et verticaux de l'armée américaine

Cette figure montre les principales familles de systèmes, les systèmes d'information, les systèmes de commande & contrôle et les systèmes d'armes, chacun comprenant des domaines verticaux entièrement contenus et des domaines horizontaux qui coupent ces systèmes, mais aussi les familles de systèmes, de manière transversale. De ce fait, les concepts liés à la planification en temps réel peuvent s'appliquer au domaine tactique de commande & contrôle, ainsi qu'à tous les domaines verticaux des systèmes d'armes. Il est donc tout à fait logique de résoudre en une seule fois les problèmes relatifs à la planification en temps réel pour tous les domaines et de traiter les connaissances et actifs ainsi développés comme un domaine distinct, qui sera ensuite associé, par exemple, à la guerre électronique, mais pas aux systèmes d'information des troupes.

Sommaire

L'architecture de référence a le même format que le Produit : Document d'architecture logicielle et ses modèles associés, dénués de références spécifiques à un projet ou dotés de références et caractéristiques de projet génériques. L'architecture de référence peut donc être classée sans problème dans la base d'actifs. En général, les modèles associés au document d'architecture logicielle sont des modèles de cas d'utilisation, des modèles de conception, des modèles d'implémentation ou des modèles de déploiement.

L'accès à ce document et aux modèles associés fournit à l'architecte logiciel plusieurs points d'entrée ; il peut décider de n'utiliser que les parties conceptuelles ou logiques de l'architecture (si les règles de l'organisation relatives à la réutilisation l'y autorisent). A l'opposé, l'architecte logiciel peut être en mesure d'extraire de la base d'actifs des sous-systèmes complets en état de fonctionnement et un modèle de déploiement à un niveau physique (c'est-à-dire, une empreinte complète de matériel et de réseau).

D'autres produits de prise en charge sont nécessaires pour rendre utilisables les actifs d'architecture. 

  1. Le modèle de cas d'utilisation décrit le comportement de l'architecture, mais l'architecte logiciel aura également besoin de connaître ses propriétés non fonctionnelles. Ces deux éléments (le modèle de cas d'utilisation et les exigences non fonctionnelles) peuvent avoir été enregistrés auparavant dans la spécification des exigences logicielles. En s'appuyant sur cette base, l'architecte logiciel pourra déterminer dans quelle mesure l'architecture de référence répond aux exigences en vigueur.

  2. L'utilisation, et plus précisément la modification, de l'architecture nécessitera autant d'assistance que le développement initial. Par exemple, l'architecte logiciel aura besoin de connaître les règles appliquées lors de la formation de l'architecture de référence, ainsi que les difficultés éventuelles liées à la modification des interfaces. Les instructions de conception associées à l'architecture de référence contiennent des informations permettant de répondre à ces questions.

  3. (facultatif) Il peut également être utile de réviser les plans de test existants en rapport avec le sujet. Ces plans de test permettront à l'architecte de prendre connaissance des stratégies de test et d'évaluation utilisées précédemment pour tester des architectures similaires et sont donc susceptibles de faciliter la compréhension des faiblesses potentielles de l'architecture.

  4. (facultatif) Il peut également être utile de réviser les architectures d'automatisation des tests et les spécifications d'interface de test existants en rapport avec le sujet. Grâce à ces produits, l'architecte prend connaissance des requêtes possibles demandant que l'architecture facilite les tests.

Description principale

Organisation des actifs

L'organisation qui possède les actifs d'architecture de référence devra déterminer la façon dont ces actifs seront classés et organisés afin d'en faciliter la récupération par l'architecte logiciel, en faisant correspondre 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 n'entrent pas actuellement dans la portée de RUP, il est possible d'organiser les architectures autour de l'idée développée dans la Définition d'un terme : Domaine, selon laquelle un domaine définit les connaissances et concepts relatifs à un aspect d'un système ou à une famille de systèmes. Nous autorisons ici l'utilisation du terme "domaine" à des niveaux inférieurs à celui de l'application. Dans ce sens, il diffère légèrement de certaines définitions (par exemple, celle présentée dans [HOF99]), mais correspond bien à celle présentée dans [LMFS96] :

"Domaine de gamme de produits : ensemble borné de fonctions (présentes et/ou futures) défini pour faciliter la communication, l'analyse et l'ingénierie afin d'identifier, de concevoir et de gérer la banalisation sur une gamme de produits. Ce type de domaine peut inclure des groupes étroitement liés de systèmes d'utilisateurs finals, des fonctions couramment utilisées sur des systèmes multiples ou des regroupements à application très large de services sous-jacents."

Cette définition signifie que les éléments utilisés pour composer des systèmes peuvent également appartenir à un domaine qu'il est intéressant d'étudier pour lui-même. La figure ci-dessous, extraite de [LMFS96], illustre ce principe.

Domaines horizontaux et verticaux de l'armée américaine

Domaines horizontaux et verticaux de l'armée américaine

Cette figure montre les principales familles de systèmes, les systèmes d'information, les systèmes de commande & contrôle et les systèmes d'armes, chacun comprenant des domaines verticaux entièrement contenus et des domaines horizontaux qui coupent ces systèmes, mais aussi les familles de systèmes, de manière transversale. De ce fait, les concepts liés à la planification en temps réel peuvent s'appliquer au domaine tactique de commande & contrôle, ainsi qu'à tous les domaines verticaux des systèmes d'armes. Il est donc tout à fait logique de résoudre en une seule fois les problèmes relatifs à la planification en temps réel pour tous les domaines et de traiter les connaissances et actifs ainsi développés comme un domaine distinct, qui sera ensuite associé, par exemple, à la guerre électronique, mais pas aux systèmes d'information des troupes.

Sommaire

L'architecture de référence a le même format que le Produit : Document d'architecture logicielle et ses modèles associés, dénués de références spécifiques à un projet ou dotés de références et caractéristiques de projet génériques. L'architecture de référence peut donc être classée sans problème dans la base d'actifs. En général, les modèles associés au document d'architecture logicielle sont des modèles de cas d'utilisation, des modèles de conception, des modèles d'implémentation ou des modèles de déploiement.

L'accès à ce document et aux modèles associés fournit à l'architecte logiciel plusieurs points d'entrée ; il peut décider de n'utiliser que les parties conceptuelles ou logiques de l'architecture (si les règles de l'organisation relatives à la réutilisation l'y autorisent). A l'opposé, l'architecte logiciel peut être en mesure d'extraire de la base d'actifs des sous-systèmes complets en état de fonctionnement et un modèle de déploiement à un niveau physique (c'est-à-dire, une empreinte complète de matériel et de réseau).

D'autres artefacts de prise en charge sont nécessaires pour rendre utilisables les actifs d'architecture. 

  1. Le modèle de cas d'utilisation décrit le comportement de l'architecture, mais l'architecte logiciel aura également besoin de connaître ses propriétés non fonctionnelles. Ces deux éléments (le modèle de cas d'utilisation et les exigences non fonctionnelles) peuvent avoir été enregistrés auparavant dans la spécification des exigences logicielles. En s'appuyant sur cette base, l'architecte logiciel pourra déterminer dans quelle mesure l'architecture de référence répond aux exigences en vigueur.

  2. L'utilisation, et plus précisément la modification, de l'architecture nécessitera autant d'assistance que le développement initial. Par exemple, l'architecte logiciel aura besoin de connaître les règles appliquées lors de la formation de l'architecture de référence, ainsi que les difficultés éventuelles liées à la modification des interfaces. Les instructions de conception associées à l'architecture de référence contiennent des informations permettant de répondre à ces questions.

  3. (facultatif) Il peut également être utile de réviser les plans de test existants en rapport avec le sujet. Ces plans de test permettront à l'architecte de prendre connaissance des stratégies de test et d'évaluation utilisées précédemment pour tester des architectures similaires et sont donc susceptibles de faciliter la compréhension des faiblesses potentielles de l'architecture.

  4. (facultatif) Il peut également être utile de réviser les architectures d'automatisation des tests et les spécifications d'interface de test existants en rapport avec le sujet. Grâce à ces artefacts, l'architecte prend connaissance des requêtes possibles demandant que l'architecture facilite les tests.

Propriétés
Facultatif
PlanifiéYes
Personnalisation
Options de représentationReprésentation UML : exemples de vues d'architecture en rapport avec le sujet : cas d'utilisation, logique, processus, déploiement, implémentation, données.

A moins que le système soit totalement inédit, l'applicabilité des architectures de référence doit être étudiée (applicabilité au domaine et au type de développement) si elles existent et sont accessibles à l'organisation en charge du développement. La création d'architectures de référence doit être traitée au niveau de l'organisation. Il est sans doute possible de tirer avantage de la réutilisation d'architecture sans suivre tous les conseils prodigués dans ce document. Par exemple, il est possible de ne pas avoir recours au modèle de test, mais, dans ce cas, les tests devront être réécrits en cas de modification de l'architecture. On peut au minimum s'attendre à l'utilisation d'un modèle de conception et de descriptions de comportement associées (peut-être un modèle de cas d'utilisation). Un élément en moins et il est difficile de considérer cet actif comme une architecture de référence. Il ferait toutefois un pattern tout à fait correct.