Pour les applications monothread, j'aime utiliser des diagrammes de classes pour avoir un aperçu de l'architecture de cette application. Ce type de diagramme, cependant, n'a pas été très utile lorsque vous essayez de comprendre des applications fortement multithread / simultanées, par exemple parce que différentes instances d'une classe "vivent" sur différents threads (ce qui signifie que l'accès à une instance n'est enregistré que depuis celle-ci) fil qu'il vit). Par conséquent, les associations entre les classes ne signifient pas nécessairement que je peux appeler des méthodes sur ces objets, mais à la place, je dois faire cet appel sur le thread de l'objet cible.
La plupart de la littérature que j'ai creusée sur le sujet, comme la conception d'applications simultanées, distribuées et en temps réel avec UML par Hassan Gomaa, avait de bonnes idées, comme dessiner des limites de threads dans des diagrammes d'objets, mais dans l'ensemble, cela semblait un peu trop académique et verbeux pour être vraiment utile.
Je ne veux pas utiliser ces diagrammes comme une vue de haut niveau du domaine problématique, mais plutôt comme une description détaillée de mes classes / objets, de leurs interactions et des limitations dues aux limites de threads que j'ai mentionnées ci-dessus.
Je voudrais donc savoir:
- Quels types de diagrammes avez-vous trouvé les plus utiles pour comprendre les applications multithread?
- Existe-t-il des extensions à UML classique qui prennent en compte les particularités des applications multi-thread, par exemple à travers des annotations illustrant que
- certains objets peuvent vivre dans un certain thread tandis que d'autres n'ont aucune affinité de thread;
- certains champs d'un objet peuvent être lus à partir de n'importe quel thread, mais écrits dans un seul;
- certaines méthodes sont synchrones et renvoient un résultat tandis que d'autres sont asynchrones qui mettent les requêtes en file d'attente et renvoient des résultats par exemple via un rappel sur un thread différent.