Para aplicaciones de subproceso único, me gusta usar diagramas de clase para obtener una visión general de la arquitectura de esa aplicación. Sin embargo, este tipo de diagrama no ha sido muy útil cuando se trata de comprender aplicaciones con múltiples subprocesos / concurrentes, por ejemplo, porque diferentes instancias de una clase "en vivo" en diferentes subprocesos (lo que significa que el acceso a una instancia se guarda solo desde el único hilo que vive). En consecuencia, las asociaciones entre clases no necesariamente significan que puedo llamar a métodos en esos objetos, sino que tengo que hacer esa llamada en el hilo del objeto de destino.
La mayoría de la literatura que he desenterrado sobre el tema, como Diseño de aplicaciones concurrentes, distribuidas y en tiempo real con UML por Hassan Gomaa, tenía algunas buenas ideas, como dibujar límites de hilos en diagramas de objetos, pero en general parecía demasiado académico y prolijo para Ser realmente útil.
No quiero usar estos diagramas como una vista de alto nivel del dominio del problema, sino como una descripción detallada de mis clases / objetos, sus interacciones y las limitaciones debidas a los límites de los hilos que mencioné anteriormente.
Por lo tanto, me gustaría saber:
- ¿Qué tipos de diagramas le han resultado más útiles para comprender las aplicaciones de subprocesos múltiples?
- ¿Hay alguna extensión de UML clásico que tenga en cuenta las peculiaridades de las aplicaciones de subprocesos múltiples, por ejemplo, a través de anotaciones que ilustran que
- algunos objetos pueden vivir en un determinado hilo mientras que otros no tienen afinidad de hilo;
- algunos campos de un objeto pueden leerse desde cualquier hilo, pero escribirse solo desde uno;
- algunos métodos son síncronos y devuelven un resultado, mientras que otros son asíncronos que obtienen solicitudes en cola y devuelven resultados, por ejemplo, a través de una devolución de llamada en un hilo diferente.
fuente
Respuestas:
La idea más importante sobre cómo ocurren las ejecuciones de subprocesos se puede representar mediante lo que se conoce como diagrama de secuencia . Aquí hay un ejemplo de wikipedia
Este diagrama esencialmente dibuja la lista de eventos junto con una dirección sobre una sola línea vertical a menudo llamada línea de vida . En este caso, cada hilo es propietario de su propia línea de vida. El diagrama permite la representación de todo tipo de eventos como síncrono, asíncrono, etc.
La otra cosa más importante en tales sistemas son los gráficos de estado o los diagramas de estado. Por lo general, esto solo se aplica si el modelo se representa como una máquina de estados. Sin embargo, en la mayoría de los sistemas de subprocesos múltiples (donde los subprocesos no son triviales), es mejor que estén diseñados para funcionar con algoritmos aislados para diferentes estados.
Hay otros tipos de diagramas como el diagrama de interacción y el diagrama de comunicación, pero creo que tratar de dibujar el diagrama de secuencia y los diagramas de estado proporcionará la máxima claridad.
fuente
Mi respuesta es complementaria a la de Dipan en que involucra diagramas de secuencia UML. Descubrí que un estilo que no es 100% puro UML también está bien. Echar un vistazo a los diagramas utilizados en los patrones de concurrencia . Algunos son casi como UML (pero este definitivamente no es estándar):
Si está familiarizado con esperar / notificar en la sincronización de subprocesos de Java, apreciará el siguiente diagrama de secuencia del documento que mencioné:
fuente
Para aplicaciones de subprocesos múltiples que usan la misma clase, el truco podría ser arrastrar y soltar la misma clase en cada modelo que representa un hilo. Podría tener la misma clase con diferentes vistas y navegar en el modelo y el código haciendo clic en la clase, el diagrama o el código. Sé que la combinación de modelos no es un concepto bien conocido, pero funciona muy bien dentro de Eclipse con Omondo.
Quiero decir que cuando modelo una aplicación grande que está compuesta por más de un proyecto. Creo un modelo para cada proyecto y luego los fusiono dentro de un proyecto más grande. Todo el modelado se realiza utilizando diagramas de clase, que es el modelo que obtuve al invertir el proyecto completo de código Java a UML. Quiero decir que en mi ejemplo utilizo el código existente y lo invierto en un solo modelo UML y luego combino todo este código inverso que ha creado los modelos UML en un solo modelo grande. También puede crear varios modelos en lugar de invertir el código existente. Funciona en ambos sentidos: en la creación sin código o en la etapa de ingeniería inversa con el código existente.
No sé si tiene sentido, pero ¿podrías crear un modelo grande, reagrupando submodelos para cada hilo como lo que hago con el modelado de proyectos múltiples? Espero que esto ayude.
fuente