Diagrammes UML des applications multithread

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:

1. Quels types de diagrammes avez-vous trouvé les plus utiles pour comprendre les applications multithread?
2. 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.

Les informations les plus importantes sur la façon dont les exécutions de thread se produisent peuvent être représentées par ce que l'on appelle un diagramme de séquence . Voici un exemple de wikipedia

Ce diagramme trace essentiellement la liste des événements ainsi qu'une direction sur une seule ligne verticale souvent appelée ligne de vie . Dans ce cas, chaque thread est propriétaire de sa propre ligne de vie. Le diagramme permet de représenter tous les types d'événements tels que synchrones, asynchrones, etc.

L'autre chose la plus importante dans de tels systèmes est les diagrammes d'état ou les diagrammes d'état. Habituellement, cela ne s'applique que si le modèle est représenté comme une machine à états. Cependant, dans la plupart des systèmes multithreads (où les threads ne sont pas triviaux), il est préférable qu'ils soient conçus pour fonctionner avec des algorithmes isolés pour différents états.

Il existe d'autres types de diagrammes comme le diagramme d'interaction et le diagramme de communication, mais je pense qu'essayer de dessiner un diagramme de séquence et des diagrammes d'état apportera une clarté maximale.

Ma réponse est complémentaire à celle de Dipan en ce qu'elle implique des diagrammes de séquence UML. J'ai trouvé qu'un style qui n'est pas 100% pur UML est OK aussi. Jetez un œil aux diagrammes utilisés dans les modèles de concurrence . Certains sont presque comme UML (mais celui-ci n'est certainement pas standard):

Si vous connaissez l'attente / notification dans la synchronisation des threads Java, vous apprécierez le diagramme de séquence suivant du document que j'ai mentionné:

Pour les applications multithreads utilisant la même classe, l'astuce pourrait être de glisser-déposer la même classe dans chaque modèle représentant un thread. Vous pourriez avoir la même classe avec des vues différentes et naviguer dans le modèle et le code en cliquant sur la classe, le diagramme ou le code. Je sais que la fusion de modèles n'est pas un concept bien connu, mais cela fonctionne très bien au sein d'Eclipse avec Omondo.

Je veux dire que lorsque je modélise une grande application qui est composée de plusieurs projets. Je crée un modèle pour chaque projet, puis je les fusionne dans un projet plus grand. Toute la modélisation est effectuée à l'aide de diagrammes de classes, qui est le modèle que j'ai obtenu lors de l'inversion du projet complet du code java en UML. Je veux dire que dans mon exemple, j'utilise le code existant et l'inverse en un seul modèle UML, puis fusionne tout ce code inverse qui a créé des modèles UML en un seul grand modèle. Vous pouvez également créer plusieurs modèles plutôt que d'inverser le code existant. Cela fonctionne dans les deux sens: à la création sans code ou au stade de la rétro-ingénierie avec le code existant.

Je ne sais pas si cela a du sens mais vous pourriez peut-être créer un grand modèle, regroupant des sous-modèles pour chaque thread comme ce que je fais avec la modélisation multi-projets? J'espère que cette aide.