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 est enregistré uniquement à partir de celle 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 Conception d'applications simultanées, distribuées et en temps réel avec UML par Hassan Gomaa = avait quelques bonnes idées, comme dessiner les limites des fils 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 par 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 illustrées par ce que l'on appelle 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 diagramme d'interaction et diagramme de communication mais je pense essayer de dessiner diagramme de séquence et diagrammes d'état apportera une clarté maximale.
Ma réponse est complémentaire de Dipan's 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 également correct. Jetez un œil aux diagrammes utilisés dans Modèles de concurrence . Certains sont presque comme UML (mais celui-ci n'est certainement pas standard):
Si vous êtes familiarisé avec l'attente/notification dans 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 vraiment bien au sein d'Eclipse avec Omondo.
Je veux dire que lorsque je modélise une grande application 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 de Java vers UML. Je veux dire que dans mon exemple, j'utilise le code existant et l'inverse en un seul Modèle UML, puis fusionnez tout ce code inversé qui a créé des modèles UML en un seul grand modèle. Vous pouvez également créer plusieurs modèles plutôt que inverser le code existant. Cela fonctionne dans les deux sens, à la création sans code ou au stade de l'ingénierie inverse 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.