Modéliser une ISR (Interrupt Service Routine)

Bonjour,

Je voudrais modéliser une ISR (Interrupt Service Routine) ou "interrupt handler", et je ne sais pas comment m'y prendre, le contexte est celui d'un système embarqué, un microcontrôleur plus précisément.

En gros, on peut dire qu'une interruption est un événement, un message ou un signal envoyé par un périphérique (Timer, etc...) à un moment quelconque, et qui exécutera une procédure ou une suite d'instructions, comment je pourrais représenter ça avec un diagramme de classes pour avoir une vue statique :? ainsi qu'avec des diagrammes d'états, d'activités, de séquences, OU de communication pour avoir une vue dynamique ?

Je vous remercie d'avance pour vos suggestions.

Bonjour,

Le mieux est d'utiliser une activité avec des régions interruptibles, exemple issue de la norme :

Pièce jointe 145901

Les timer sont des "activity accept event action", ils ont une représentation dédiée :
Pièce jointe 145903

Merci pour ta réponse, est ce que sur le diagramme que tu as posté, l'état "order cancel request" pourrait être assimilé à une interruption (IRQ - le signal) ou à une ISR (le handler - le code qui sera exécuté par l'événement) ?
la partie qui est limité par un rectangle dont les lignes sont discontinues est la "région interruptible" n'est ce pas ? pourquoi elle n'est pas plus étendue, en fait, comment définir les "limites" de cette région, sur quelle critère faut-il se baser ? et qu'est ce que ça implique vraiment ? que les 3 états (receive order, fill order et ship order) peuvent être interrompu par "order cancel request" ? et comment revenir à cette zone interruptible une fois que l'interruption a achevé son travail ? (rendre le contexte d'exécution ou ce n'est pas possible ?)

j'avais mal compris la demande, pour juste montrer l'exécution du handler d'une IT alors un simple "accept event action" suivit des actions effectuée par le handler suffit

on utilise une région interruptible dans le cas où l'exécution dans la région cesse, où il y a déroutement

ben le soucis, c'est que dans la région interruptible, je ne fais rien, je n'ai pas d'activités, en effet, une autre tâche ou le programme principal peut continuer à faire ce qu'ils veulent, mais ils seront interrompus par l'interruption hardware du Timer pour exécuter l'ISR (ou une activité) en rapport avec le diagramme d'activité que je suis entrain de produire.

Dans mon diagramme, je ne veux voir apparaître que des activités en liaison avec mon cas d'utilisation (par exemple : comment la communication I²C software qui utilise les interruptions pour envoyer les bits fonctionne - je sais j'aurai pu faire plus simple en utilisant une boucle mais là je ne veux pas que le CPU perde son temps à faire des temporisations avec des boucles)

J'ai quand même mis dans la région interruptible une activité "Idle" avec une note qui précise qu'on "rend la main" au programme principale ou à une tâche (ou thread) mais je ne trouve pas ça beau, expressif :? c'est une activité qui n'a pas de lien direct avec le scénario du cas d'utilisation que je suis entrain de modéliser.

et puis contrairement à la spécification UML, dans mon cas, les activités qui se trouvent dans la région interruptible ne sont pas perdues, elles sont seulement préemptées.

:aie: dur dur d'utiliser UML dans le monde de l'embarqué.

comme je l'ai dit dans ma réponse précédente tu n'as pas de région interruptible, tu as juste un "accept event action" correspondant à ton timer suivit des actions effectuée lorsqu'il sonne

Ah d'accord, si on reprend le modèle que tu as posté précédemment , on enlève la région interruptible, et on utilise le "pentagone" "order cancel request" pour modéliser l'interruption , quant à "Cancel ordre" lui représente l'ISR, c'est ça ?

au fait, le "accept event action" c'est bien ce qui se trouve à l'intérieur du pentagone non ? c'est juste pour vérifier !

En gros, on aura deux branches discontinues, la deuxième commence avec l' "accept event action" c'est pas très gênant, étant donné, que l'interruption Timer ne pourra être déclenchée que si on atteint la fin de la première branche pour que le Timer soit opérationnel (dans la dernière activité de la première branche se trouve la configuration et l'activation du périphérique Timer)

oui le "accept event action" c'est le pentagone, dans le cas d'un timer il devient le double triangle de ma première réponse (tictac)

On ne modélise pas l'interruption en tant que telle mais sa réception/acceptation via le "accept event action", suivit d'un flux amenant à ce qui est exécuté dans le handler. Un "accept event" n'est pas précédé d'un flux, son exécution est "spontanée".

Je ne mettrais que ce qui correspondant au timer dans le diagramme, ton IT s'exécute en parallèle à tout, pas seulement à une partie spécifique. Le fait que le timer soit ou non activé est un autre problème à montrer par ailleurs ou juste indiquer par une description textuelle

je te remercie pour tes conseils :)