Instructions: Document d'architecture logicielle
Ces instructions présentent une vue d'ensemble du contenu du document d'architecture logicielle.
Relations
Description principale

Références

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 :

  1. Documents externes
  2. Documents internes
  3. Documents gouvernementaux
  4. Documents non gouvernementaux
  5. etc.

Objectifs et limitations de l'architecture

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

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 :

  1. Le nom du cas d'utilisation.
  2. Une brève description du cas d'utilisation.
  3. 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.
  4. 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.
  5. Une énumération des diagrammes de cas d'utilisation importants qui sont liés au cas d'utilisation.
  6. 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.
  7. Des images de l'interface utilisateur graphique importantes, qui clarifient le cas d'utilisation.
  8. Les réalisations de ces cas d'utilisation doivent se trouver dans la vue logique.

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 :

  1. 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.

  2. Packages de conception importants pour l'architecture

    Pour chaque package important, insérez une sous-section comprenant les informations suivantes :

    1. Son nom.
    2. Une brève description.
    3. 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.
    4. 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.
  3. 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 :

    1. Le nom du cas d'utilisation réalisé.
    2. Une brève description de ce cas.
    3. 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.
    4. Une énumération des diagrammes de classes et d'interaction importants qui sont liés à la réalisation de cas d'utilisation.
    5. 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

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 :

  1. Son nom.
  2. Les processus impliqués.
  3. 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.

La vue de déploiement

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 :

  1. Son nom.
  2. Un diagramme de déploiement qui illustre la configuration, suivi d’un mappage des processus vers chaque processeur.
  3. 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.

La vue d’implémentation

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 :

  1. 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.

  2. Couches

    Pour chaque couche, insérez une sous-section comprenant les informations suivantes :

    1. Son nom.
    2. Un diagramme de composants qui illustre les sous-systèmes d’implémentation et leurs dépendances à l'importation.
    3. Si nécessaire, un aperçu des relations entre les couches et les éléments de la vue logique ou de processus.
    4. 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.

La vue de données

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.).

Taille et performances

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.

Qualité

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.