La section des références indique les documents externes qui fournissent des informations de base importantes pour la
compréhension de l'architecture du système. Si les références sont nombreuses, structurez cette section en différentes
sous-sections :
-
Documents externes
-
Documents internes
-
Documents gouvernementaux
-
Documents non gouvernementaux
-
etc.
L'architecture sera construite en fonction des exigences suivantes :
-
Les exigences fonctionnelles, enregistrées dans le modèle de cas d'utilisation.
-
Les exigences non fonctionnelles, enregistrées dans les spécifications supplémentaires.
Cependant, la réalisation d'une architecture ne repose par sur ces seuls éléments. Des limitations sont en effet
imposées par l'environnement dans lequel doit être exécuté le logiciel, la nécessité de réutiliser certains actifs,
l'imposition de différentes normes, l'exigence de compatibilité avec des systèmes existants, etc. De plus, il peut
y avoir un certain nombre de règles et principes d'architecture préexistants qui viseront à guider le
développement, et dont l'élaboration et la vérification seront nécessaires au projet. Cette section du document
d'architecture logicielle donne l'occasion de décrire ces objectifs et limitations, ainsi que toutes les décisions
d'architecture qui en dérivent et qui ne trouvent pas leur place ailleurs (contrairement aux exigences).
Lors de la création de ce document, il est important de spécifier l'environnement d'implémentation, en particulier : la
plateforme cible (matériel, système d'exploitation), le système de fenêtrage, les outils de développement (langage,
générateur d'interface utilisateur graphique), le système de gestion de base de données et les bibliothèques de
composants. Il est également recommandé de spécifier les technologies d'interface utilisateur qui sont autorisées
et celles qui ne le sont pas. De nombreux systèmes choisissent de ne pas utiliser certaines technologies de
présentation (JavaScript, Applets, Frames, XML, etc.), afin de rendre l'utilisation de l'application accessible au plus
grand nombre de systèmes client ou de faciliter le développement de l'application. Les décisions sont capturées
ici dans le document d'architecture logicielle, alors que les détails d'utilisation et de mise en oeuvre des
technologies choisies est documenté dans le Produit : Instructions spécifiques au projet.
La mise en application de ces décisions passe par la définition d'un ensemble de critères d'évaluation de
l'architecture, qui seront utilisés dans le cadre de l'évaluation des itérations.
Les critères d'évaluation se fondent également sur les cas de changement. Ces derniers contiennent des
informations sur les changements à venir potentiels concernant :
-
Les capacités et les propriétés du système.
-
La manière dont le système est utilisé.
-
Les environnements de support et d'exploitation du système.
Les cas de changement expliquent les propriétés du système, décrites à l'aide de phrases subjectives, telles que :
"simple à étendre", "simple à porter", "simple à maintenir", "robuste en cas de changement" et "rapide à développer".
Ils insistent moins sur ce qui est possible, que sur ce qui est important et probable.
Ils essaient de prédire les changements, mais leurs prédictions s'avèrent rarement exactes.
Les propriétés d'un système sont déterminées par les utilisateurs, les décideurs, les fournisseurs, les développeurs et
d'autres parties prenantes. Il existe plusieurs moteurs de changement, par exemple :
-
L'évolution du métier : création et modification d'objectifs et de processus métier.
-
L'évolution technologique : adaptation du système à de nouvelles plateformes, intégration à de nouveaux composants.
-
Les changements concernant les profils de l'utilisateur moyen.
-
Les changements concernant les besoins d'intégration aux autres systèmes.
-
Les changements de portée du fait de la migration d'une fonctionnalité à partir de systèmes externes.
La vue de cas d'utilisation est un sous-ensemble du Produit : modèle de cas d'utilisation, qui décrit les cas
d'utilisation du système importants pour l'architecture. Elle décrit l'ensemble des scénarios et/ou cas d'utilisation
qui représentent une fonctionnalité importante et centrale. Elle décrit également un ensemble de scénarios et/ou de cas
d'utilisation qui présentent une couverture architecturale importante (qui concernent de nombreux éléments de
l'architecture) ou qui illustrent un point spécifique particulièrement délicat de l'architecture.
Si le modèle est vaste, il sera généralement organisé en packages. Par souci de clarté, la vue de cas d'utilisation
doit également être organisée en packages, dans la mesure du possible. Pour chaque cas d'utilisation important, insérez
une sous-section comprenant les informations suivantes :
-
Le nom du cas d'utilisation.
-
Une brève description du cas d'utilisation.
-
Des descriptions importantes concernant le flot d'événements du cas d'utilisation. Il peut s'agir de toute
la description du flot d'événements, ou de sous-sections décrivant les flux ou scénarios importants du cas
d'utilisation.
-
Des descriptions importantes sur les relations auxquelles participe le cas d'utilisation, telles que les relations
d'inclusion et d'extension ou les associations de communication.
-
Une énumération des diagrammes de cas d'utilisation importants qui sont liés au cas d'utilisation.
-
Des descriptions importantes relatives aux exigences particulières du cas d'utilisation. Il peut s'agir de
toute la description des exigences particulières, ou de sous-sections décrivant les exigences importantes.
-
Des images de l'interface utilisateur graphique importantes, qui clarifient le cas d'utilisation.
-
Les réalisations de ces cas d'utilisation doivent se trouver dans la vue logique.
La vue logique est un sous-ensemble du Produit
: modèle de conception, qui présente des éléments de conception importants pour l'architecture. Elle décrit les
principales classes, l'organisation des classes en packages et en sous-systèmes, et l'organisation de ces derniers en
couches. Elle décrit également les réalisations de cas d'utilisation les plus importantes, telles que les aspects
dynamiques de l'architecture.
Un système complexe peut nécessiter un certain nombre de sections pour décrire la vue logique :
-
Vue d'ensemble
Cette sous-section décrit la décomposition générale du modèle de conception selon une hiérarchie de packages et
de couches. Si le système comporte plusieurs niveaux de packages, vous devez d'abord décrire les packages les
plus importants au niveau le plus élevé. Incluez tout diagramme qui représente les packages importants de plus
haut niveau, ainsi que leurs interdépendances et leurs couches. Présentez ensuite les packages importants du
niveau juste en-dessous, et ainsi de suite jusqu'aux packages importants qui se situent tout en bas de la
hiérarchie.
-
Packages de conception importants pour l'architecture
Pour chaque package important, insérez une sous-section comprenant les informations suivantes :
-
Son nom.
-
Une brève description.
-
Un diagramme reprenant toutes les classes et packages importants contenus dans ce package. Si nécessaire,
ce diagramme pourra comporter des classes d'autres packages pour être plus clair.
-
Chaque classe importante doit être associée à un nom, à une brève description et éventuellement à une
description de ses responsabilités, opérations et attributs majeurs. Si nécessaire, décrivez également ses
relations importantes afin de mieux comprendre les diagrammes inclus.
-
Réalisations de cas d'utilisation
Cette section illustre le fonctionnement du logiciel en mentionnant quelques réalisations de cas d'utilisation
(ou de scénarios) sélectionnées et explique comment les différents éléments du modèle de conception contribuent
à leur fonctionnalité. Les réalisations sélectionnées pour cette section représentent une fonctionnalité
importante et centrale du système final, une couverture architecturale importante (elles concernent un grand
nombre d'éléments d'architecture), ou soulignent ou illustrent un point d'architecture particulièrement
délicat. Les cas d'utilisation et scénarios correspondants doivent se trouver dans la vue de cas d'utilisation.
Pour chaque réalisation de cas d'utilisation importante, insérez une sous-section comprenant les informations
suivantes :
-
Le nom du cas d'utilisation réalisé.
-
Une brève description de ce cas.
-
Des descriptions importantes concernant le flot d'événements - conception de la réalisation de cas
d'utilisation. Il peut s'agir de toute la description du flot d'événements - conception, ou de
sous-sections décrivant la réalisation des flux ou scénarios importants du cas d'utilisation.
-
Une énumération des diagrammes de classes et d'interaction importants qui sont liés à la réalisation de cas
d'utilisation.
-
Des descriptions importantes relatives aux exigences associées de la réalisation de cas
d'utilisation. Il peut s'agir de toute la description des exigences associées, ou de sous-sections
décrivant les exigences importantes.
Eléments de conception importants pour l'architecture
Pour vous aider à identifier les éléments importants pour l'architecture, nous vous présentons quelques exemples
d'éléments candidats, accompagnés d'une description de leurs caractéristiques :
-
Un élément de modèle qui encapsule une abstraction essentielle du domaine concerné, tel que :
-
un plan de vol dans un système de contrôle de la circulation aérienne
-
un employé dans un système de fiches de paye
-
un abonné dans un système de téléphonie
Il n'est pas nécessaire d'inclure les sous-types. Par exemple, la distinction entre un plan de vol OACI et
un plan de vol intérieur n'est pas importante : tous deux sont des plans de vol et ont en commun une grande
quantité d'attributs et d'opérations.
La distinction entre un abonné à une ligne de données ou à une ligne voix n'a pas d'importance tant que le
traitement des appels s'effectue à peu près de la même manière.
-
Un élément de modèle utilisé par de nombreux autres éléments de modèle.
-
Un élément de modèle qui encapsule un mécanisme (service) essentiel du système.
-
Des mécanismes de conception :
-
mécanisme de persistance (référentiel, base de données et gestion de mémoire)
-
mécanisme de communication (appel RPC, diffusion, service de courtier)
-
traitement d'erreurs ou mécanisme de reprise sur incident
-
mécanisme d'affichage et autres interfaces communes (fenêtrage, acquisition de données, conditionnement de
signal, etc.)
-
mécanismes de paramétrage
En général, tout mécanisme susceptible d'être utilisé dans de nombreux packages différents (contrairement à ceux qui
sont internes à un package), et pour lesquels il est recommandé d'utiliser une seule implémentation commune sur tout le
système, ou tout au moins une seule interface qui masque différentes possibilités d'implémentation.
-
Un élément de modèle qui participe à une interface essentielle du système, comme :
-
un système d'exploitation
-
un produit standard (système de fenêtrage, SGBD relationnel, système d'information géographique)
-
une classe qui implémente ou prend en charge un pattern d'architecture (tel que les patterns de découplage
d'éléments de modèle, dont le pattern d'architecture MVC, ou le pattern de courtier).
-
Un élément de modèle qui, en dépit de sa visibilité localisée, pourrait avoir un impact considérable sur les
performances générales du système, comme :
-
un mécanisme d'interrogation pour l'analyse à très grande fréquence de capteurs
-
un mécanisme de traçage pour la résolution des incidents
-
un mécanisme d'utilisation de point de contrôle pour un système à haute disponibilité (point de contrôle et
redémarrage)
-
une séquence de démarrage
-
une mise à jour de code en ligne
-
une classe qui encapsule un algorithme nouveau et techniquement risqué, ou pour lequel la sécurité et la
sûreté sont essentielles, par exemple : le calcul du niveau de radiation, les critères d'évitement des
collisions d'avions dans les espaces aériens congestionnés, le chiffrement des mots de passe
Les critères d'identification des éléments importants évolueront lors des premières itérations du projet, à mesure que
vous découvrirez des difficultés techniques et commencerez à mieux comprendre le système. En règle générale, cependant,
vous devez classer 10 % des éléments de modèle comme "importants pour l'architecture". Sinon, vous risquez de
diluer le concept d'architecture, et "tout devient architecture".
Lorsque vous définissez et incluez dans la vue logique les éléments de modèle importants pour l'architecture, vous
devez également prendre en compte les aspects suivants :
-
Identifiez les possibilités de mise en commun ou de réutilisation. Quelles classes pourraient constituer des
sous-classes d'une classe commune ou des instances d'une même classe paramétrée ?
-
Identifiez les possibilités de paramétrage. De quelle partie de la conception pouvez-vous améliorer la
réutilisabilité ou la flexibilité à l'aide des paramètres statiques ou d'exécution (tels qu'un comportement
conditionné par les tables, ou des données de ressource chargées au démarrage) ?
-
Identifiez les possibilités d'utilisation de produits standard.
La vue de processus décrit la structure de processus du système. Etant donné que la structure de processus a un impact
important sur l'architecture, vous devez y présenter tous les processus. Au sein de ces processus, seules les unités
d'exécution simples importantes pour l'architecture doivent être présentées. La vue de processus décrit les tâches
(processus et unités d'exécution) impliquées dans l'exécution du système, leurs interactions et configurations, ainsi
que les objets et classes alloués à ces tâches.
Pour chaque réseau de processus, insérez une sous-section comprenant les informations suivantes :
-
Son nom.
-
Les processus impliqués.
-
Les interactions entre processus sous forme de diagrammes de communication, dans lesquels les objets sont des
processus effectifs qui englobent leurs propres threads de contrôle. Décrivez brièvement le comportement, la durée
de vie et les caractéristiques de communication de chaque processus.
Cette section décrit une ou plusieurs configurations physiques de réseau (matériel) sur lesquelles le logiciel est
déployé et exécuté. Elle décrit également l'allocation des tâches (depuis la vue de processus) aux noeuds
physiques. Pour chaque configuration physique de réseau, insérez une sous-section comprenant les informations suivantes
:
-
Son nom.
-
Un diagramme de déploiement qui illustre la configuration, suivi d’un mappage des processus vers chaque processeur.
-
S’il existe plusieurs configurations physiques possibles, décrivez-en une courante, puis expliquez les règles de
mappage générales à suivre pour définir les autres. Dans la plupart des cas, vous devez également décrire des
configurations de réseau pour la réalisation de simulations et tests logiciels.
Cette vue est générée depuis le Produit : modèle de déploiement.
Cette section décrit la décomposition du logiciel en couches et en sous-systèmes d'implémentation au sein du modèle
d'implémentation. Elle offre également une vue d’ensemble de l’allocation des éléments de conception (depuis la vue
logique) à l’implémentation. Elle contient deux sous-sections :
-
Vue d'ensemble
Cette sous-section nomme et définit les différentes couches et leur contenu, les règles qui régissent
l'inclusion dans une couche donnée, et les frontières entre les couches. Incluez un diagramme de composants qui
indique les relations entre les couches.
-
Couches
Pour chaque couche, insérez une sous-section comprenant les informations suivantes :
-
Son nom.
-
Un diagramme de composants qui illustre les sous-systèmes d’implémentation et leurs dépendances à
l'importation.
-
Si nécessaire, un aperçu des relations entre les couches et les éléments de la vue logique ou de processus.
-
Une énumération des sous-systèmes d’implémentation situés dans la couche. Pour chaque sous-système
d'implémentation :
-
-
Indiquez son nom, son abréviation ou son surnom, une brève description, ainsi que les raisons de
son existence.
-
Si nécessaire, indiquez les relations entre les sous-systèmes d'implémentation et les éléments de
la vue logique ou de processus. Souvent, un sous-système d’implémentation implémentera un ou
plusieurs sous-systèmes de conception de la vue logique.
-
Si un sous-système d’implémentation contient des sous-systèmes et/ou
des répertoires d'implémentation importants pour l’architecture, pensez à faire refléter cette
situation dans la hiérarchie des sous-sections.
-
Si le mappage entre un sous-système d’implémentation et un répertoire d’implémentation n'est pas de
type un à un, expliquez la définition du sous-système d’implémentation en termes de répertoires
et/ou fichiers d’implémentation.
Cette vue n’est pertinente que pour les systèmes dont la fonctionnalité de persistance est prise en charge par la base
de données. Elle décrit les éléments persistants du modèle de données importants pour l’architecture. Elle offre une
vue d’ensemble du modèle de données et son organisation en termes de tables, vues, index, déclencheurs et procédures
stockées utilisés pour assurer la fonctionnalité de persistance du système. Cette vue présente également le mappage des
classes persistantes (depuis la vue logique) vers la structure de données de la base de données.
Elle inclut généralement :
-
Le mappage depuis des classes de conception persistantes clé, en particulier lorsque ce mappage n’est pas
particulièrement simple.
-
Les éléments du système importants pour l’architecture qui ont été implémentés dans la base de données sous forme
de procédures stockées et de déclencheurs.
-
Les décisions importantes dans d’autres vues qui ont des implications au niveau des données, telles que le choix
d’une stratégie de transaction, la distribution, l'accès concurrent, la tolérance aux pannes. Par exemple, si vous
optez pour une gestion de transaction fondée sur la base de données (qui repose sur la base de données pour valider
ou avorter des transactions), le mécanisme de traitement d’erreurs de votre architecture doit utiliser une
stratégie de reprise depuis une transaction échouée qui consiste à actualiser le statut des objets de persistance
stockés dans la mémoire cache de l’application.
Vous devez présenter les éléments de modèle importants pour l’architecture, décrire leurs responsabilités, ainsi que
quelques relations et comportements très importants (déclencheurs, procédures stockées, etc.).
Cette section décrit les caractéristiques de réactivité et de volume du système qui définissent l’architecture. Les
informations indiquées pourront comprendre :
-
Le nombre d’éléments clé que le système devra gérer (tel que le nombre de vols simultanés pour un système de
contrôle de la circulation aérienne, le nombre d’appels téléphoniques simultanés pour un commutateur téléphonique,
le nombre d’utilisateurs en ligne simultanés pour un système de réservation des vols, etc.).
-
Les mesures de performance clé du système, telles que le temps de réponse moyen pour des événements clé, les débits
moyen, maximal et minimal, etc.
-
L'espace occupé (en termes de disque dur et de mémoire) par les programmes exécutables. Cette donnée est
essentielle si le système est imbriqué et que les limitations imposées sont très contraignantes.
La plupart de ces qualités sont enregistrées en tant qu'exigences. Elles sont présentées ici, car elles apportent une
contribution importante à la construction de l'architecture et méritent une attention particulière. Abordez les
modalités de prise en charge par l’architecture pour chaque exigence.
Dans cette section, répertoriez les domaines clé de qualité du système qui façonnent l’architecture. Les informations
indiquées pourront comprendre :
-
Des exigences de performance d’exploitation, telles que la moyenne des temps de bon fonctionnement (MTBF).
-
Des objectifs de qualité (par exemple : "aucune durée d'immobilisation non planifiée").
-
Des objectifs d’extensibilité (par exemple "possibilité de mise à niveau du logiciel au cours de l’exécution du
système").
-
Des objectifs de portabilité, tels que les plateformes matérielles, les systèmes d’exploitation, les langages.
Pour chaque domaine, abordez les modalités de prise en charge de l’exigence par l’architecture. Vous pouvez structurer
cette section par vue (logique, d'implémentation, etc.) ou par qualité. Lorsque des caractéristiques particulières sont
importantes dans le système, par exemple la sûreté, la sécurité ou la confidentialité, vous devez soigneusement définir
leur prise en charge par l’architecture dans cette section.
|