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ôles | Responsable:
| Modifié par:
|
Entrée vers | Obligatoire:
| Facultatif:
| Externe:
|
Sortie de |
|
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
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.
-
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.
-
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.
-
(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.
-
(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
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.
-
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.
-
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.
-
(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.
-
(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é |  |
Personnalisation
Options de représentation | Repré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.
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|