Activité :
|
Objet
|
|
Rôle : Architecte logiciel | |
Fréquence : Une fois par itération, tout particulièrement pendant la phase d'élaboration. | |
Etapes
|
|
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : |
Détails sur l'enchaînement d'activités : |
Les objets actifs (c'est-à-dire les instances de classes actives) sont utilisés pour représenter des unités d'exécution simultanées au sein du système : chaque objet actif possède sa propre unité d'exécution de contrôle et constitue la racine d'un cadre de pile d'exécution. Le mappage d'objets actifs à des unités d'exécution ou à des processus de système d'exploitation peut varier en fonction des exigences de temps de réaction et subit les influences des temps systèmes de permutation. Par exemple, il est possible, pour un certain nombre d'objets actifs et en association avec un simple outil de planification, de partager une unité d'exécution de système d'exploitation, ce qui donne l'apparence d'un fonctionnement simultané. Toutefois, si l'un des objets actifs a un comportement bloquant (par exemple s'il effectue des entrées/sorties synchrones), les autres objets actifs du groupes seront incapables de répondre aux événements qui se produiront pendant le blocage de l'unité d'exécution du système d'exploitation.
Inversement, si vous affectez à chaque objet actif sa propre unité d'exécution de système d'exploitation, cela entraîne une plus grande réactivité, sous réserve que les ressources de traitement ne soient pas affectées par le temps système de permutation supplémentaire.
Cette activité définit une architecture de processus pour le système en termes de classes actives, de leurs instances et des relations avec les unités d'exécution et les processus de système d'exploitation.
Au début de la phase d'élaboration, cette architecture est généralement préliminaire, mais les processus et les unités d'exécution doivent être bien définis à la fin de cette phase.
Les résultats de cette activité sont enregistrés dans le modèle de conception (et plus particulièrement dans la vue de processus (voir les concepts sur la vue de processus).
Objet | Définir l'étendue d'exécution des tâches requise pour le système. Cette définition aide à façonner l'architecture. |
Au cours de l'activité d'identification des éléments de conception, les exigences de simultanéité principalement associées à des demandes naturelles de simultanéité dans le domaine du problème ont été examinées.
Il en résulte un ensemble de classes actives représentant des unités logiques d'exécution de contrôle dans le système.
Cette étape permet d'examiner d'autres sources d'exigences de simultanéité (celles imposées par les exigences non fonctionnelles du système).
Les exigences de simultanéité sont établies sur la base des facteurs suivants :
Comme pour beaucoup de problèmes architecturaux, ces exigences peuvent être mutuellement exclusives. Il n'est pas rare d'observer, au moins au début, des exigences entrant en conflit. Le classement des exigences en termes d'importance aide à résoudre le conflit.
Objet | Définir les processus et les unités d'exécution qui seront présents dans le système. |
L'approche la plus simple consiste à allouer tous les objets actifs à une unité d'exécution ou à un processus et d'utiliser un outil de planification d'objets actifs : cela minimise les temps systèmes dus au changement de contexte. Dans certains cas toutefois, il peut être nécessaire de distribuer les objets actifs à un ou plusieurs processus ou unités d'exécution.
Si un objet actif partageant une unité d'exécution de système d'exploitation avec d'autres objets actifs effectue un appel synchrone à un autre processus ou à une autre unité d'exécution et que cet appel bloque l'unité d'exécution appelante, cela interrompt automatiquement tous les autres objets actifs situés dans le processus appelant. Cela ne se produit pourtant pas systématiquement : un appel synchrone du point de vue de l'objet actif peut être géré de façon asynchrone par l'outil de planification qui contrôle le groupe d'objets actifs (cet outil interrompt l'objet actif à l'origine de l'appel une fois l'appel synchrone terminé, puis planifie l'exécution d'autres objets actifs).
Lorsque l'opération synchrone d'origine prend fin, l'objet actif appelant peut être rétabli. Toutefois, il se peut que cette approche ne soit pas toujours applicable, car l'outil de planification n'est pas toujours désigné pour intercepter tous les appels synchrones avant qu'ils n'occasionnent un blocage. Vous noterez qu'un appel synchrone entre des objets actifs utilisant la même unité d'exécution ou le même processus peut en général être géré par l'outil de planification de cette façon (et correspond à un appel de procédure du point de vue de l'objet actif appelant).
Cela nous permet de déduire que les objets actifs doivent être regroupés en processus ou en unités d'exécution sur la base du besoin d'exécution simultanée avec des appels synchrones qui bloquent l'unité d'exécution. Cela signifie que le seul cas où un objet actif doit être empaqueté dans le même processus (ou une unité d'exécution avec un autre objet qui utilise les appels synchrones bloquant l'unité d'exécution) se présente lorsqu'une exécution simultanée avec cet objet est inutile et qu'il peut tolérer l'absence d'exécution pendant que l'autre objet est bloqué. Au pire, lorsque le temps de réponse est critique, cela peut conduire au besoin d'unité d'exécution ou de processus séparé pour chaque objet actif.
En règle générale, dans les situations décrites ci-dessus, il est conseillé d'utiliser des unités d'exécution légères plutôt que des processus lourds car cela implique un temps système moins important. Toutefois, vous pouvez souhaiter dans certains cas bénéficier malgré tout de certaines des caractéristiques spécifiques offertes par les processus. Les unités d'exécution partagent le même espace d'adresses, elles sont donc plus exposées au risque que les processus. Si le risque d'écrasement accidentel est pour vous une préoccupation, il est recommandé de privilégier l'utilisation de processus. En outre, dans la plupart des systèmes d'exploitation, les processus représentent des unités de reprise indépendantes ; par conséquent, il peut être utile d'allouer des objets actifs aux processus sur la base d'un besoin de reprise indépendant. Cela signifie que tous les objets actifs doivent faire l'objet d'une récupération et que les unités peuvent faire l'objet d'un package dans le même processus.
Pour chaque flux de contrôle requis par le système, créez un processus ou une unité d'exécution (processus allégé). Vous devez utiliser les unités d'exécution en cas de besoin de flux de contrôle imbriqué (lorsque dans un processus, un flux de contrôle indépendant est nécessaire au niveau des sous-tâches).
Par exemple, vous pouvez considérer que des unités d'exécution de contrôle séparées peuvent être requises dans les cas suivants (qui ne sont pas classés par ordre d'importance) :
Exemple
Sur un guichet automatique, des événements asynchrones provenant de trois sources différentes doivent être gérés : l'utilisateur du système, les unités ATM (en cas de blocage du distributeur de billets, par exemple), ou encore le réseau ATM (en cas de directive d'arrêt en provenance du réseau). Pour gérer ces événements asynchrones, vous pouvez définir trois unités d'exécution distinctes au sein d'ATM, comme illustré ci-dessous par l'utilisation de classes actives dans UML.
Processus et unités d'exécution au sein d'ATM
Objet | Identifier les périodes de création et de suppression des processus et des unités d'exécution. |
Chaque processus ou unité d'exécution de contrôle doit être créé(e) et supprimé(e). Dans une architecture à processus unique, la création a lieu au moment du lancement de l'application et la suppression au moment de la fermeture de l'application. Dans les architectures à processus multiples, de nouveaux processus (ou unités d'exécution) sont généralement générés dynamiquement à partir du processus initial créé par le système d'exploitation au moment du lancement de l'application. Ces processus doivent être formellement détruits également.
La séquence d'événements aboutissant à la création et à la suppression de processus doit être déterminée et documentée, ainsi que les mécanismes de création et de suppression.
Exemple
Sur un guichet automatique, un processus principal est lancé ; il est chargé de coordonner le comportement du système entier. A son tour, il génère automatiquement un certain nombre d'unités d'exécution de contrôle subordonnées chargées de surveiller différentes parties du système : les unités du système et les événements qui émanent du client et du réseau ATM. La création de ces processus et unités d'exécution peut être illustrée à l'aide des classes actives dans UML, et la création d'instances de ces classes actives peut être illustrée par un diagramme, comme illustré ci-dessous :
Création de processus et d'unités d'exécution au démarrage du système
Objet | Identifier les moyens de communication utilisés par les processus et les unités d'exécution. |
Les mécanismes de communication interprocessus (IPC) autorisent l'envoi de messages entre objets exécutés via des processus séparés.
Les principaux mécanismes de communication interprocessus incluent :
Le choix du mécanisme IPC modifie la façon dont le système est modélisé ; par exemple, avec une "architecture à bus", il n'est pas nécessaire d'avoir recours à des associations entre objets pour envoyer des messages.
Objet | Allouer des ressources rares Anticiper et gérer les goulets d'étranglement potentiels au niveau des performances |
Les mécanismes de communication interprocessus sont généralement rares. Les sémaphores, la mémoire partagée et les boîtes aux lettres ont généralement des tailles ou des nombres fixes qui ne peuvent pas être augmentés sans coût important. RPC, les messages et les diffusions d'événements absorbent la largeur de bande réseau qui devient de plus en plus rare. Lorsque le système dépasse un seuil de ressources, des dégradations aléatoires de performances ont lieu : une ressource rare est épuisée, les demandes ultérieures relatives à cette ressource auront sans doute des conséquences déplaisantes.
Si des ressources rares sont trop sollicitées, plusieurs stratégies sont à considérer :
Quelle que soit la stratégie sélectionnée, le système doit s'arrêter correctement et doit offrir un retour d'informations approprié à l'administrateur système pour permettre la résolution du problème (si possible) une fois le système déployé.
Si le système requiert une configuration spécifique de l'environnement d'exécution afin d'augmenter la disponibilité d'une ressource critique (souvent contrôlée par la reconfiguration du noyau du système d'exploitation), l'installation système doit effectuer cette opération automatiquement ou demander à un administrateur système de le faire avant que le système ne devienne opérationnel. Par exemple, le système peut nécessiter un redémarrage pour que la modification soit prise en compte.
Objet | Mapper les "flux de contrôle" aux concepts pris en charge par l'environnement d'implémentation. |
Les processus conceptuels doivent être mappés à des concepts spécifiques de l'environnement de fonctionnement. Dans de nombreux environnements, il existe des choix de types de processus. Ces choix prennent comme base le niveau de couplage (les processus sont autonomes, alors que les unités d'exécution sont exécutées dans le contexte d'un processus) et les exigences de performances du système (la communication interprocessus entre les unités d'exécution est généralement plus rapide et plus efficace qu'entre les processus).
Dans de nombreux systèmes, il existe un nombre maximal d'unités d'exécution par processus ou de processus par noeud. Ces limites ne sont pas toujours absolues, mais peuvent être imposées par la disponibilité des ressources rares. Les unités d'exécution et les processus déjà exécutés sur un noeud cible doivent être comptés avec les unités d'exécution et les processus proposés dans l'architecture de processus. Les résultats de l'étape antérieure (Allouer des ressources de coordination interprocessus) doivent être pris en compte lors du mappage, afin de s'assurer qu'aucun nouveau problème de performances n'est en train de se préparer.
Objet | Déterminer les classes et les sous-systèmes d'unités d'exécution de contrôle à exécuter. |
Les instances d'une classe ou d'un sous-système spécifique doivent s'exécuter au sein d'une unité d'exécution de contrôle (au minimum) offrant l'environnement d'exécution adapté à la classe ou au sous-système ; en réalité, elles peuvent s'exécuter dans plusieurs processus différents.
A l'aide de deux stratégies différentes utilisées simultanément, vous pouvez déterminer la "bonne" quantité de simultanéité et définir les éléments "appropriés" suivants :
Ce processus n'est pas linéaire et n'aboutit pas à une vue de processus optimale ; il requiert quelques itérations pour pouvoir atteindre un compromis acceptable.
Exemple
Le diagramme ci-après illustre la façon dont les classes, au sein d'ATM, sont distribuées aux différents processus et unités d'exécution du système.
Mappage des classes aux processus pour ATM
RUP (Rational Unified Process)
|