Concept: Analyse descendante des exigences supplémentaires
L'analyse descendante des exigences supplémentaires est la technique permettant de dériver les exigences non-fonctionnelles pour les éléments d'analyse (puis de conception).
Relations
Description principale

Introduction

Dans le cadre du processus d'analyse, l'architecte développe un diagramme de localisation initial. La vue Localisation est une synthèse des considérations non-fonctionnelles et fournit un contexte permettant de définir la manière dont sont traitées les exigences non-fonctionnelles telles que la fiabilité et la capacité.

La pratique courante en matière d'ingénierie autorise la budgétisation de la capacité, des taux d'incidents autorisés, etc. Cet effort produit un ensemble d'exigences supplémentaires dérivées pour chaque élément de localisation. Les caractéristiques de localisation sont déterminées à partir de ces exigences. Les exigences et caractéristiques dérivées sont réexaminées lorsque le partitionnement des sous-systèmes (entre localisations) est établi et détaillé.

Les exigences supplémentaires au niveau du système ont également une incidence sur les sous-systèmes eux-mêmes (matériel, logiciels, personnes), dans le sens où les caractéristiques du sous-système se combinent à celles de la localité pour produire les caractéristiques système souhaitées.

Mesures de la qualité de service

La qualité de service (QoS) est une notion qui inclut certains aspects des exigences non-fonctionnelles. La liste de ces caractéristiques est potentiellement conséquente et comprend de nombreuses "capacités" telles que la fiabilité, la maintenabilité et la convivialité, et éventuellement des spécialités d'ingénierie complètes telles que la sécurité, les facteurs humains, etc. Les problèmes majeurs d'ingénierie spécialisée sont généralement traités par des experts des disciplines concernées. Les problèmes dont la résolution incombe souvent à l'ingénieur système et logiciel sont ceux qui ont trait aux éléments suivants :

  • Performances - dans quelle mesure le système effectue-t-il bien ses fonctions dans le temps, c'est-à-dire quelles sont sa réactivité et son rendement et respecte-t-il ses échéances ?
  • Fiabilité/Tolérance aux pannes - combien de temps le système peut-il continuer à effectuer ses fonctions obligatoires avant un échec, et gère-t-il bien les échecs partiels ? La moyenne des temps de bon fonctionnement (MTBF) du système est une mesure de la fiabilité.
  • Maintenabilité - est-il aisé de maintenir le système en fonctionnement et de diagnostiquer et corriger les incidents qui s'y produisent ? Le temps moyen de reprise du système (MTTR) est une mesure de la maintenabilité.

Avant de construire le système, l'ingénieur système doit souvent s'appuyer sur des modèles du système pour définir des solutions alternatives et pour affecter et budgétiser les exigences non fonctionnelles. Ces modèles sont analysés afin de voir dans quelle mesure ils répondent aux niveaux de qualité de service désirés et une solution peut ensuite être retenue (le coût étant généralement un facteur). Ces études commerciales sont importantes dans la conception du système, à tous les niveaux d'amélioration. La synthèse des solutions candidates dépend dans une large mesure des compétences et de l'expérience de l'architecte. L'analyse de ces solutions (par un recours à la modélisation mathématique, à la simulation, etc) devrait être relativement mécanique. Quand bien même, la fiabilité de ces analyses varie considérablement en fonction de la validité des données d'entrée et de la fidélité des modèles.

Un ensemble de techniques permet de simplifier l'analyse des modèles quant aux mesures de qualité de service mentionnées ci-dessus - citons, par exemple, l'analyse RMA (Rate Monotonic Analysis)  pour l'étude des performances des systèmes logiciels temps réel embarqués [voir Klein, M. H., et al. A Practitioners' Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993], et l'analyse AMDEC (analyse des modes de défaillance, de leurs effets et de leur criticité), pour l'analyse et la caractérisation des incidents matériels et des risques de sécurité [voir Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 2,  PTR Prentice Hall, 1991].

La prise en charge de ces types d'analyses est en train d'être ajoutée au langage UML par la fourniture de profils, notamment le « UML Profile for Schedulability, Performance, and Time Specification » et le « UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms ». Ces profils (disponibles sur le site www.omg.org) définissent des annotations pour les modèles UML qui leur permettent d'être analysés au niveau des caractéristiques définies dans le profil et des prédictions quantitatives effectuées au sujet de ces caractéristiques, par un recours à divers outils et techniques d'analyse quantitative des modèles existants et à venir.