Rubriques

Références Haut de la page

La section références présente des documents externes fournissant des informations de base importantes pour comprendre l'architecture du système. S'il existe un grand nombre de références, organisez la section en sous sections :

  1. documents externes
  2. documents internes
  3. documents gouvernementaux
  4. documents non-gouvernementaux
  5. etc.

Objectifs et contraintes de l'architecture Haut de la page

L'architecture sera créée en prenant en compte :

  • les exigences fonctionnelles, consignées dans le modèle de cas d'utilisation, et
  • les exigences non-fonctionnelles, consignées dans les spécifications supplémentaires

Cependant, ce ne sont pas les seules influences qui définiront l'architecture : il y aura des contraintes imposées par l'environnement dans lequel le logiciel doit fonctionner; par la nécessité de réutiliser les atouts existants ; par l'imposition de diverses normes ; par un besoin de comptabilité avec les systèmes existants, etc. Il peut également avoir un ensemble de principes et règles architecturales pré-existants qui guideront le développement et devront être élaborés et réifiés pour le projet. Cette section du document d'architecture logicielle permet de décrire ces objectifs et ces contraintes, et toutes les décisions architecturales qui en découlent et qui ne trouvent pas leur place (en tant qu'exigences) ailleurs.  

Lors de la création de ce document, la spécification de l'environnement d'implémentation est un élément important. La plate-forme 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 des bases de données et les bibliothèques de composants constituent des exemples d'éléments à spécifier.  Il est aussi très utile de préciser les technologies d'interface utilisateur autorisées et celles qui ne le sont pas. De nombreux systèmes choisissent de ne pas utiliser de techniques de présentation (JavaScript, Applets, Frames, XML, etc.) pour que plus de systèmes clients soient capables d'utiliser l'application, ou pour faciliter son développement.  Les décisions sont consignées ici dans le document d'architecture logicielle

La mise en application de ces décisions est effectuée en délimitant un ensemble de critères d'évaluation de l'architecture qui seront utilisés en tant qu'éléments de l'évaluation d'itération.

Les critères d'évaluation sont également extraits des cas de changement qui documentent les changements futurs potentiels sur :

  • les capacités et les propriétés du système
  • la façon dont le système est utilisé
  • les environnements d'exploitation et de prise en charge du système

Les cas de changement éclaircissent les propriétés du système décrites par des phrases subjectives comme "facile à accroître ", "facile à porter", "facile à maintenir", "solide face au changement", et "rapide à développer". Les cas de changement mettent l'accent sur ce qui est important et probable et non sur ce qui est possible.

Les cas de changement tentent de prévoir les changements : ce type de prédiction est rarement complètement exact.

Les propriétés d'un système sont déterminées par les utilisateurs, les commanditaires, les fournisseurs, les développeurs, et les autres parties prenantes. Les changements peuvent avoir de nombreuses sources, par exemple :

  • Déclencheurs métier : processus et objectifs métiers nouveaux et modifiés
  • Déclencheurs de technologie : adaptation du système aux nouvelles plate-formes, intégration à de nouveaux composants
  • Variations dans les profils de l'utilisateur moyen
  • Variations dans les besoins d'intégration à d'autres systèmes
  • Changements de portée dus à la migration de la fonctionnalité à partir de systèmes externes

Vue de cas d'utilisation Haut de la page

La vue de cas d'utilisation présente un sous-ensemble de l'Artefact : modèle de cas d'utilisation, qui présente les cas d'utilisation du système architecturalement importants. Elle décrit l'ensemble de scénarios et/ou de cas d'utilisation qui représentent une fonctionnalité importante et centrale. Elle décrit également l'ensemble de scénarios et/ou de cas d'utilisation qui possèdent une couverture architecturale importante (qui utilise de nombreux éléments architecturaux) ou qui soulignent ou illustrent un point spécifique et délicat de l'architecture.

Si le modèle est plus important, il sera généralement organisé en packages ; pour faciliter la compréhension la vue de cas d'utilisation doit également être organisée en packages, s'ils sont prêts à utiliser. Pour chaque cas d'utilisation important, inclure une sous-section contenant les informations suivantes :

  1. Le nom du cas d'utilisation.
  2. Une brève description du cas d'utilisation.
  3. Des descriptions significatives du flot d'événements du cas d'utilisation. Il peut s'agir de la description complète du flot d'événements ou de sous-sections décrivant les flots ou les scénarios significatifs du cas d'utilisation.
  4. Des descriptions significatives des relations impliquant le cas d'utilisation, comme les relations d'inclusion et d'extension, ou les associations de communication.
  5. Une énumération des diagrammes de cas d'utilisation importants liés au cas d'utilisation.
  6. Des descriptions significatives des exigences spécifiques du cas d'utilisation. Il peut s'agir de la description complète des exigences spécifiques ou de sous-sections décrivant des exigences importantes.
  7. Des images importantes de l'interface utilisateur, éclaircissant le cas d'utilisation.
  8. Les réalisations de ces cas d'utilisation doivent se trouver dans la vue logique.

Vue logique Haut de la page

La vue logique est un sous-ensemble de l'Artefact : Modèle de conception qui présente les éléments de conception importants architecturalement. Elle décrit les classes les plus importantes, leur organisation en packages et en sous-systèmes, et l'organisation de ces packages et sous-systèmes en couches. Elle décrit également les réalisations de cas d'utilisation les plus importantes, par exemple, les aspects dynamiques de l'architecture.

Un système complexe peut nécessiter qu'un certain nombre de sections décrivent la vue logique :

  1. Présentation

    Cette sous-section décrit la décomposition globale du modèle de conception en terme de l'historique et des couches de son package. Si le système possède plusieurs niveaux de packages, vous devez d'abord décrire les packages importants globaux. Incluez les diagrammes montrant les packages importants globaux, ainsi que leurs interdépendances et leur organisation en couches. Les packages du niveau juste en dessous sont présentés ensuite, et ainsi de suite jusqu'aux packages qui se situent tout en bas de la hiérarchie.

  2. Packages de conception importants architecturalement

    Pour chaque package important, inclure une sous-section avec les informations suivantes

    1. Son nom.
    2. Brève description.
    3. Diagramme possédant toutes les classes et les packages importants contenus dans le package. Pour une meilleure compréhension ce diagramme peut montrer des classes d'autres packages si nécessaire.
    4. Pour chaque classe importante du package, incluez son nom, une brève description, et éventuellement une description de quelques responsabilités, opérations et attributs les plus importants. Décrivez également ses relations importantes si nécessaire pour comprendre les diagrammes inclus.
  3. Réalisations de cas d'utilisation

    Cette section illustre le fonctionnement du logiciel en présentant quelques réalisations de cas d'utilisation (ou scénarios), et explique comment les différents éléments du modèle de conception contribuent à ce fonctionnement. Les réalisations données ici sont choisies car elles représentent une fonctionnalité importante du système final- ou du fait de leur couverture architecturale (grand nombre d'éléments d'architecture concernés), ou car elles soulignent ou illustrent un point d'architecture spécifique et délicat. Les cas d'utilisation et les scénarios de ces réalisations correspondants doivent se trouver dans la vue de cas d'utilisation.

    Pour chaque réalisation importante de cas d'utilisation, inclure une sous-section contenant les informations suivantes

    1. Nom du cas d'utilisation réalisé.
    2. Brève description du cas d'utilisation réalisé.
    3. Descriptions importantes du flot d'événements - conception de la réalisation de cas d'utilisation. Il peut s'agir de la description complète du flot d'événements - conception ou de sous-sections décrivant les flots ou les scénarios significatifs du cas d'utilisation.
    4. Une énumération des interactions ou des diagrammes de classe importants liés à la réalisation de cas d'utilisation.
    5. Descriptions importantes des exigences dérivées de la réalisation de cas d'utilisation. Il peut s'agir de la description complète des exigences dérivées ou de sous-sections décrivant les exigences importantes.

Eléments de conception importants architecturalement

Pour permettre de décider des éléments importants architecturalement, vous trouverez ci-dessous quelques exemples d'éléments adaptés ainsi que leurs caractéristiques :

  • Un élément de modèle encapsulant une abstraction importante du domaine du problème, tel que :
    • Un plan de vol dans un système de contrôle du trafic aérien.
    • Un salarié dans un système de paye.
    • Un abonné dans un système téléphonique.

    Il n'est pas nécessaire d'inclure des sous-types de ces éléments, par exemple il n'est pas important de distinguer un plan de vol type OACI d'un plan de vol intérieur aux Etats-Unis ; il s'agit de deux plans de vol et ils partagent un nombre important d'attributs et d'opérations.

    Il est inutile de distinguer un abonné avec une ligne de données et une ligne à fréquences vocales dans la mesure où le traitement des appels suit sensiblement le même processus.

  • Un élément de modèle utilisé par de nombreux autres éléments de modèle.
  • Un élément de modèle encapsulant un mécanisme (service) crucial du système
  • Mécanismes de conception
    • Mécanisme de persistance (référentiel, base de données, gestion de la mémoire).
    • Mécanisme de communication (appel de procédure à distance, diffusion, service de courtier).
    • Traitement des erreurs ou mécanisme de récupération.
    • Mécanisme d'affichage, et autres interfaces communes (fenêtrage, capture de données, prétraitement des signaux, etc.).
    • Mécanismes de paramétrage.

En général, tout mécanisme susceptible d'être utilisé dans de nombreux packages différents (plutôt que complètement internes à un package), et pour lequel il est sage d'avoir une seule implémentation commune dans le système global, ou au moins une seule interface masquant différentes implémentations alternatives.

  • Un élément de modèle participant à une interface majeure du système avec, par exemple :
    • Un système d'exploitation.
    • Un produit général (système de fenêtrage, système de gestion de base de données relationnelle, système d'information géographique).
    • Une classe qui implémente ou prend en charge un modèle architectural (comme les modèles pour les éléments de dé-couplage, y compris le modèle de contrôleur de la vue de modèle, ou le modèle de courtier).
  • Un élément de modèle dont la visibilité est localisée, mais qui peut avoir un impact très important sur la performance globale du système, par exemple :
    • Un mécanisme d'interrogation pour scanner les capteurs à un taux très élevé.
    • Un mécanisme de traçage pour le dépannage.
    • Un mécanisme de jalonnement des points de reprise pour un système à haute disponibilité (point de reprise et redémarrage).
    • Une séquence de démarrage.
    • Une mise à jour de code en ligne.
    • Une classe encapsulant un algorithme nouveau et techniquement risqué, ou un algorithme à sécurité ou à sûreté critique, par exemple : calcul du niveau d'irradiation ; critère permettant d'éviter la collision d'avions pour les espaces aériens congestionnés; chiffrement de mot de passe.

Le critère déterminant ce qui est important architecturalement évoluera dans les premières itérations du projet, au fur et à mesure que vous rencontrerez des difficultés techniques et commencerez à mieux comprendre le système. Cependant, en règle générale vous devez définir un maximum de 10% des éléments de modèle comme "architecturalement importants." Sinon vous risquez d'édulcorer le concept d'architecture, et "tout est de l'architecture."

Lorsque vous définissez et incluez les éléments de modèles architecturalement importants dans la vue logique, vous devez également prendre en compte les aspects suivants

  • Identifier le potentiel de banalisation et de réutilisation. Quelles classes doivent être des sous-classes d'une classe commune, ou des instances de la même classe paramétrée?
  • Identifier le potentiel de paramétrage. Quelle partie de la conception peut être rendue plus réutilisable ou plus flexible en utilisant des paramètres statiques et de délai d'exécution (comme le comportement défini par tableau, ou les données de ressource chargées au moment du démarrage)?
  • Identifier le potentiel d'utilisation des produits standards.

Vue de processus Haut de la page

La vue de processus décrit la structure de processus du système. Dans la mesure où la structure de processus a un grand impact architectural, tous les processus doivent être présentés. Dans les processus, seuls les fils extra-minces ayant une grande importance architecturale doivent être présentés. La vue de processus décrit les tâches (processus et fils) impliquées dans l'exécution du système, leurs interactions et configurations, ainsi que l'attribution d'objets et de classes aux tâches.

Pour chaque réseau de processus, inclure une sous-section contenant les informations suivantes :

  1. Son nom.
  2. Les processus concernés.
  3. Les interactions entre les processus sous la forme de diagrammes de communication, dans lesquels les objets sont de véritables processus qui comprennent leurs propres fils de contrôle. Pour chaque processus, décrivez brièvement son comportement, sa durée de vie et ses caractéristiques de communication.

Vue de déploiement Haut de la page

Cette section décrit une ou plusieurs configuration(s) réseau physique(s) sur laquelle (lesquelles) le logiciel est déployé et exécuté. Elle décrit également l'attribution des tâches (de la vue de processus) aux noeuds physiques. Pour chaque configuration de réseau physique, inclure une sous-section contenant les informations suivantes :

  1. Son nom.
  2. Un diagramme de déploiement illustrant la configuration, suivi d'un mappage des processus à chaque processeur.
  3. S'il existe des configurations physiques potentielles, décrivez une configuration commune et expliquez les règles générales de mappage à suivre pour définir d'autres configurations. Vous devez également inclure, dans la majorité des cas, des descriptions des configurations réseaux pour l'exécution de tests et de simulations logiciels.

Cette vue est générée à partir de l'Artefact : Modèle de déploiement.

Vue d'implémentation Haut de la page

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 présente également brièvement l'attribution d'éléments de conception (de la vue logique) à l'implémentation. Elle contient deux sous-sections :

  1. Présentation

    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. Pensez à inclure un diagramme des composants qui indique les relations entre les couches.

  2. Couches

    Pour chaque couche, inclure une sous-section contenant les informations suivantes :

    1. Son nom.
    2. Un diagramme de composant montrant les sous-systèmes d'implémentation et leurs dépendances d'importation.
    3. Si cela est adapté, une brève description de la relation de la couche aux éléments de la vie 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 :
      • Donnez son nom, son abréviation ou pseudonyme, une brève description, et une justification de son existence ;
      • Si cela est adapté, indiquez la relation du sous-système d'implémentation aux éléments de la vue logique ou de processus. Dans de nombreux cas, un sous-système d'implémentation implémentera un ou plusieurs sous-systèmes de conception à partir de la vue logique.
      • Si un sous-système d'implémentation contient des sous-systèmes d'implémentation et/ou
        des répertoires architecturalement importants, envisagez d'exprimer ce fait dans la hiérarchie de la sous-section.
      • Si un sous-système d'implémentation ne peut être mappé exactement avec un répertoire d'implémentation, incluez une explication de la manière dont le sous-système d'implémentation est défini en termes de répertoires et/ou de fichiers d'implémentation.

Vue de données Haut de la page

Cette vue décrit les éléments persistants architecturalement importants dans le modèle de données. Elle décrit brièvement le modèle de données et son organisation en terme de tableaux, vues, index, déclencheurs et procédures stockées utilisés pour fournir une persistance au système. Elle décrit également le mappage des classes persistantes (à partir de la vue logique) à la structure de données de la base de données

Cela inclut généralement :

  • Le mappage à partir de classes de conception persistantes clé, en particulier lorsque le mappage n'est pas trivial.
  • Les parties du système architecturalement importantes qui ont été implantées dans la base de données, sous la forme de procédures stockées et de déclencheurs.
  • Les décisions importantes dans d'autres vues qui ont des implications en terme de données, comme le choix d'une stratégie de transaction, la distribution, la simultanéité, la tolérance aux pannes. Par exemple, le choix d'utiliser la gestion de transaction par base de données (en s'appuyant sur la base de données pour archiver ou annuler des transactions) exige que le mécanisme de traitement des erreurs utilisé dans l'architecture inclut une stratégie pour récupérer d'une transaction échouée en rafraîchissant l'état des objets de persistance en cache dans la mémoire de l'application.

Vous devez présenter des éléments de modèle de données architecturalement importants, décrire leurs responsabilités, ainsi que quelques relations et comportements très importants (déclencheurs, procédures stockées, etc.).

Taille et performance Haut de la page

Cette section décrit des caractéristiques volumétriques et de réactivité du système, définissant l'architecture. Les informations présentées peuvent comporter les éléments suivants :

  • Le nombre d'éléments clé que le système devra traiter (comme le nombre de vols simultanés pour un système de contrôle du trafic aérien, le nombre d'appels téléphoniques simultanés pour un centre d'hébergement des communications, le nombre d'utilisateurs simultanés en ligne pour un système de réservation d'une compagnie aérienne, etc.).
  • Les mesures clé de performance du système, comme le temps de réponse moyen pour les événements clé, les taux de débit minimum et maximum, etc.
  • L'encombrement (en termes de disque et de mémoire) des exécutables - essentiel dans le cas d'un système embarqué qui doit vivre dans des contraintes très limitées.

La majorité de ces qualités sont consignées en tant qu'exigences ; elles sont présentées ici car elles définissent l'architecture de manière importante et garantissent une focalisation particulière. Pour chaque exigence, examinez comment l'architecture prend en charge cette exigence.

Qualité Haut de la page

Dans cette section, listez les domaines de qualité clé du système qui définissent l'architecture. L'information présentée peut inclure :

  • Exigences de performance d'exploitation, comme la durée moyenne de fonctionnement avant défaillance (MTBF).
  • Cibles de qualité, comme le "aucun temps d'arrêt imprévu"
  • Cibles de capacité d'extension, comme "le logiciel pourra être mis à jour pendant l'exécution du système".
  • Cibles de portabilité, comme les plate-formes matériel, les systèmes d'exploitation, les langues.

Pour chaque dimension, examinez comment l'architecture prend en charge cette exigence. Vous pouvez organiser cette section selon les différentes vues (logique, d'implémentation, etc.) ou selon la qualité. Lorsque des caractéristiques spécifiques sont importantes pour le système, par exemple la sécurité, la sûreté ou la confidentialité, la prise en charge architecturale de celles-ci doit être décrite avec soin dans cette section.



RUP (Rational Unified Process)   2003.06.15