Objet
  • Analyser les exigences de simultanéité pour identifier les processus et les mécanismes de communication interprocessus, allouer des ressources de coordination interprocessus, identifier les cycles de vie des processus et distribuer les éléments de modèle aux processus.
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).

Analyser les exigences de simultanéité Haut de la page

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 :

  • Le niveau de distribution du système. Un système dont le comportement doit être distribué à plusieurs processeurs ou noeuds nécessite virtuellement une architecture multiprocessus. Un système qui utilise un système de gestion de base de données ou un gestionnaire de transactions doit également examiner les processus que ces sous-systèmes majeurs introduisent.
  • L'intensité de calcul des algorithmes clés. Pour pouvoir offrir de bons temps de réponse, il peut être nécessaire d'incorporer des activités intensives à un processus ou à une unité d'exécution indépendant(e) afin que le système soit capable de répondre aux entrées des utilisateurs pendant l'exécution des calculs, même si les ressources utilisées sont moins nombreuses.
  • Le niveau d'exécution parallèle pris en charge par l'environnement. Si le système d'exploitation ou l'environnement ne prend pas en charge les unités d'exécution (processus légers), il est inutile d'examiner leur impact sur l'architecture du système.
  • Le besoin de tolérance aux pannes dans le système. Les processeurs de secours ont besoin d'utiliser un processus de secours et occasionnent un besoin de synchronisation des processus principaux et de secours.
  • Le pattern de survenue d'événements dans le système. Dans les systèmes dotés d'unités externes ou de détecteurs, les patterns de survenue d'événements entrants peuvent varier selon les détecteurs. Certains événements peuvent être périodiques (c'est-à-dire qu'ils interviennent à intervalle fixe, plus ou moins une faible valeur) ou non périodiques (c'est-à-dire qu'ils se produisent à intervalles irréguliers). Les classes actives représentant des unités qui génèrent différents patterns d'événements sont généralement affectés à différentes unités d'exécution de système d'exploitation et sont associés à différents algorithmes de planification, afin de garantir que les événements ou les délais de traitement sont respectés (s'il s'agit d'une exigence du système).

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.

Identifier les processus et les unités d'exécution Haut de la page

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

  • Questions distinctes entre différentes zones du logiciel
  • Avantage des UC multiples sur un ou plusieurs noeuds au sein d'un système distribué
  • Augmentation de l'utilisation de l'UC via l'allocation de cycles à d'autres activités lorsqu'une unité d'exécution de contrôle est arrêtée
  • Classement des activités par ordre de priorité
  • Partage de charge entre plusieurs processus et processeurs
  • Augmentation de la disponibilité système grâce à la sauvegarde des processus
  • Support du SGBD, du gestionnaire de transactions ou d'autres sous-systèmes importants.

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.

Illustration des processus et unités d'exécution ATM

Processus et unités d'exécution au sein d'ATM

Identifier les cycles de vie des processus Haut de la page

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 :

Illustration de la création de processus et d'unités d'exécution au démarrage du système

Création de processus et d'unités d'exécution au démarrage du système

Identifier les mécanismes de communication interprocessus Haut de la page

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 :

  • mémoire partagée, avec ou sans sémaphores afin de garantir la synchronisation.
  • Rendezvous, tout particulièrement adapté aux langages tels que Ada
  • Sémaphores, utilisé pour bloquer les accès simultanés aux ressources partagées
  • Acheminement de messages, tant point à point que point à multipoint
  • Boîtes aux lettres
  • RPC - Appel de procédure éloigné
  • Diffusion d'événements - avec utilisation d'un "bus logiciel" ("architecture à bus")

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.

Allouer des ressources de coordination interprocessus Haut de la page

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 :

  • réduction du besoin de la ressource rare via la réduction du nombre de processus
  • modification de l'utilisation des ressources rares (pour un ou plusieurs processus, choisissez une ressource différente, moins rare que vous utiliserez pour le mécanisme IPC))
  • augmentation de la quantité de ressource rare (en augmentant par exemple le nombre de sémaphores). Vous pouvez le faire pour des modifications relativement réduites, mais comporte souvent des effets secondaires ou des limites.
  • partage de la ressource rare (par exemple en allouant la ressource uniquement lorsque cela est nécessaire). Cette solution est onéreuse et risque d'être annonciateur de crise.

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.

Mapper les processus au sein de l'environnement d'implémentation Haut de la page

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.

Mapper les éléments de conception aux unités d'exécution de contrôle Haut de la page

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 :

Intérieur-extérieur

  1. En commençant par le modèle de conception, regroupez les classes et les sous-systèmes en ensembles d'éléments qui (a) coopèrent étroitement et (b) doivent être exécutés sur la même unité d'exécution de contrôle. Tenez compte de l'impact de l'introduction de la communication interprocessus au milieu d'une séquence de messages avant de séparer les éléments en unités d'exécution de contrôle distinctes.
  2. Séparez les classes et les sous-systèmes qui n'interagissent pas du tout, en les plaçant dans des unités d'exécution de contrôle séparées.
  3. Ces clusters sont effectués jusqu'à ce que le nombre de processus ait diminué jusqu'à atteindre le nombre le plus limité autorisant la distribution et l'utilisation des ressources physiques.

Extérieur-intérieur

  1. Identifiez les stimuli externes auxquels le système doit répondre. Définissez une unité d'exécution de contrôle séparée pour la gestion de chaque stimuli et une unité d'exécution serveur pour fournir chaque service.
  2. Examinez les contraintes d'intégrité et de sérialisation des données pour réduire cet ensemble initial d'unités d'exécution de contrôle jusqu'à atteindre le nombre pouvant être pris en charge par l'environnement d'exécution.

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.

Illustration de la distribution ATM des classes aux processus et aux unités d'exécution

Mappage des classes aux processus pour ATM



RUP (Rational Unified Process)   2003.06.15